On Wednesday 16 March 2011, Philippe De Muyter wrote:
Just a small remark : when I run --open-au with a high --open-au-nr= value (here higher than 4 or 5), it takes a very very long time to complete for the smaller block size.
Yes, this is the main thing that flashbench is good for: pinpoint the exact pattern that drives a card into its worst-case scenario.
Every row writes exactly one erase block, but when the card runs out of open blocks, a single access in there causes it to garbage- collect another block, the scenario described in this animation: https://lwn.net/Articles/428799/.
In earlier version of flashbench, I would do the --open-au test automatically for a number of settings, like your one-line script does. However, I could not find a good way to stop at the right point, so I decided to make it more manual.
tmp179:~ # smartctl --all -T permissive /dev/sdc smartctl 5.40 2010-10-16 r3189 [i686-pc-linux-gnu] (SUSE RPM) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION === Device Model: ELITE PRO CF CARD 4GB Serial Number: 5B921800 Firmware Version: Ver2.21K User Capacity: 4,034,838,528 bytes
Could you also do 'hdparm -i /dev/sdc'? I've added another column in the table for the highest supported PIO/DMA modes.
Are you using UDMA mode?
4 sched_setscheduler: Operation not permitted 2MiB 4.07M/s 1MiB 4.07M/s 512KiB 3.2M/s 256KiB 2.69M/s 128KiB 3M/s 64KiB 3.67M/s 32KiB 3.01M/s 16KiB 2.67M/s 8KiB 2.09M/s 4KiB 1.3M/s 5 sched_setscheduler: Operation not permitted 2MiB 4.07M/s 1MiB 3.74M/s 512KiB 2.69M/s 256KiB 1.54M/s 128KiB 924K/s 64KiB 450K/s 32KiB 232K/s 16KiB 116K/s 8KiB 52.9K/s 4KiB 26.7K/s
Ok, excellent. It's very clear here that the opmimum I/O size is 64 KB and that 5 open allocation units are not supported, but 4 are. Since the numbers are almost identical between the --random and linear tests, the algorithm used here can write pages randomly within the erase block.
tmp179:~ # ./flashbench --findfat --fat-nr=10 --erasesize=$[2 * 1024 * 1024] /dev/sdc --random --blocksize=512 sched_setscheduler: Operation not permitted 2MiB 3.14M/s 4.07M/s 4.07M/s 4.07M/s 4.07M/s 4.06M/s 4.06M/s 4.06M/s 2.53M/s 4.08M/s 1MiB 3.64M/s 3.65M/s 3.15M/s 3.15M/s 3.34M/s 3.34M/s 3.33M/s 3.34M/s 3.34M/s 3.35M/s 512KiB 2.67M/s 2.68M/s 2.68M/s 2.66M/s 2.61M/s 2.6M/s 2.6M/s 2.62M/s 2.62M/s 2.63M/s 256KiB 2.33M/s 2.33M/s 2.34M/s 2.34M/s 2.33M/s 2.31M/s 2.32M/s 2.33M/s 2.32M/s 2.3M/s 128KiB 2.81M/s 2.8M/s 2.82M/s 2.8M/s 2.81M/s 2.82M/s 2.81M/s 2.81M/s 2.8M/s 2.82M/s 64KiB 3.44M/s 3.46M/s 3.44M/s 3.46M/s 3.45M/s 3.43M/s 3.44M/s 3.45M/s 3.46M/s 3.43M/s 32KiB 3.11M/s 3.1M/s 3.09M/s 3.09M/s 3.11M/s 3.09M/s 3.1M/s 3.08M/s 3.1M/s 3.09M/s 16KiB 2.65M/s 2.65M/s 2.64M/s 2.64M/s 2.64M/s 2.65M/s 2.64M/s 2.66M/s 2.65M/s 2.64M/s 8KiB 1.69M/s 2.06M/s 2.07M/s 2.06M/s 2.06M/s 2.09M/s 2.1M/s 2.09M/s 2.1M/s 2.12M/s 4KiB 1.31M/s 1.32M/s 1.31M/s 1.32M/s 1.31M/s 1.31M/s 1.31M/s 1.32M/s 1.33M/s 1.31M/s 2KiB 806K/s 806K/s 793K/s 792K/s 805K/s 793K/s 800K/s 795K/s 801K/s 797K/s 1KiB 445K/s 449K/s 449K/s 446K/s 452K/s 448K/s 447K/s 447K/s 448K/s 450K/s 512B 237K/s 235K/s 234K/s 234K/s 235K/s 235K/s 237K/s 237K/s 236K/s 235K/s
Nothing to see regarding the FAT here, but the page size is 4 KB: writing 2 KB blocks is roughly have the throughput of 8 KB, and every lower row further halves this number, while anything above 4 KB is just slightly slower than the row above it.
All in all, the card is much better than any Kingston SD card I've seen, especially the 4KB page size means that it's actually usable with ext3. The total throughput is really low though, but that may be a result of the interface speed.
Arnd