Hello!
I'm relatively new to linux (been working with it for 7 or 8 months now), primarily using and contributing to the Porteus Linux community. Porteus is a distro that is optimized to run from a cd, USB flash drive, CF, SD, or other portable bootable media. As such, I'm trying to improve my knowledge of how flash devices work and how to best optimize them for use under linux (and, thus, it seems we may have some common goals).
Arnd, your article at LWN as well as the information you've posted at linaro and to this mailing list has been a great help to me -- thank you for your time and efforts!
I have three flash drives ( an 8GB Kingston DataTraveller DT101 G2, which doesn't seem to match up with the results you've already posted on the flash card survey for an 8GB DataTraveller, a 4GB Lexar JumpDrive TwistTurn, and an old 1GB USB1.1 unnamed drive that I received as a gift). I benched the Kingston and Lexar models yesterday, but somehow flashbench or one of the other commands I ran during the process wiped out the MBR and partition tables on both drives, and I've lost almost all of my data. The only thing I've been able to salvage so far is the results for the Lexar drive. I'll send along results for the others, and if I can figure out what I did to hose my drives I'll report on that as well (if you have any good recommendations for recovering data, I'm all ears! I've tried testdisk, dd_rescue, and scalpel without much luck --this could just be my lack of skill lol. Scalpel was able to get some text scattered around, which is how I got the Lexar results back).
Ok, on to the results:
## Note -- this drive is 2-3 years old, give or take.
bash-4.1# Bus 002 Device 004: ID 05dc:a764 Lexar Media, Inc.
bash-4.1# fdisk -lu /dev/sdc
Disk /dev/sdc: 4009 MB, 4009754624 bytes 128 heads, 16 sectors/track, 3824 cylinders, total 7831552 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77ac9c58
Device Boot Start End Blocks Id System /dev/sdc1 * 49152 3637247 1794048 83 Linux /dev/sdc2 3637248 7831551 2097152 83 Linux bash-4.1#
## In an effort to improve performance without really knowing the erasesize of this drive, I started my partitions on 24MB intervals (least common denominator for all of the common allocation unit sizes on the flash card survey) and set my cylinder size to be one MB (I don't know if cylinder size, sectors/track, etc., really matters, since the FS block sizes don't match up to the page sizes anyway, but I thought it was worth a try). However, this didn't really help my performance very much. I should note that partition sdc1 was actually formatted as FAT32, and sdc2 was formatted as EXT4.
bash-4.1# hdparm -I /dev/sdc
/dev/sdc: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATA device, with non-removable media Standards: Likely used: 1 Configuration: Logical max current cylinders 0 0 heads 0 0 sectors/track 0 0 -- Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 0 MBytes device size with M = 1000*1000: 0 MBytes cache/buffer size = unknown Capabilities: IORDY not likely Cannot perform double-word IO R/W multiple sector transfer: not supported DMA: not supported PIO: pio0 bash-4.1#
cat /proc/partitions 8 32 3915776 sdc 8 33 1794048 sdc1 8 34 2097152 sdc2
bash-4.1# ./flashbench -a /dev/sdc --blocksize=1024 --count=100 align 1073741824 pre 846µs on 867µs post 849µs diff 19.8µs align 536870912 pre 817µs on 866µs post 815µs diff 49.2µs align 268435456 pre 809µs on 855µs post 811µs diff 45.3µs align 134217728 pre 819µs on 856µs post 794µs diff 49.6µs align 67108864 pre 814µs on 857µs post 808µs diff 45.6µs align 33554432 pre 809µs on 857µs post 806µs diff 49.5µs align 16777216 pre 818µs on 862µs post 813µs diff 46.2µs align 8388608 pre 808µs on 861µs post 805µs diff 54.7µs align 4194304 pre 798µs on 857µs post 804µs diff 56.3µs align 2097152 pre 833µs on 862µs post 814µs diff 38.1µs align 1048576 pre 829µs on 881µs post 818µs diff 57µs align 524288 pre 829µs on 884µs post 826µs diff 56.2µs align 262144 pre 849µs on 886µs post 807µs diff 58.1µs align 131072 pre 849µs on 876µs post 832µs diff 35.8µs align 65536 pre 837µs on 884µs post 824µs diff 53.7µs align 32768 pre 824µs on 883µs post 831µs diff 55µs align 16384 pre 833µs on 881µs post 833µs diff 48.7µs align 8192 pre 832µs on 875µs post 820µs diff 48.6µs align 4096 pre 827µs on 880µs post 831µs diff 51.4µs align 2048 pre 833µs on 821µs post 831µs diff -11049n bash-4.1#
##I wasn't sure, but I assumed that this means I have a 4MB erase block -- my numbers were even more inconsistent before I added the count=100 option. I also made a number of scatter plots for this drive, with and without offsets to different locations on the drive, and it showed a straight line for 24+MB (whereas my kingston drive showed very clear jumps at 4MB intervals).
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.62M/s 2MiB 7.08M/s 1MiB 7.05M/s 512KiB 7.05M/s 256KiB 7.09M/s 128KiB 7.1M/s 64KiB 7.1M/s 32KiB 7.03M/s 16KiB 6.92M/s 8KiB 6.64M/s 4KiB 2.79M/s 2KiB 1.29M/s 1KiB 620K/s bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 7.42M/s 2MiB 7.4M/s 1MiB 7.34M/s 512KiB 6.19M/s 256KiB 7.36M/s 128KiB 7.34M/s 64KiB 7.35M/s 32KiB 7.28M/s 16KiB 7.13M/s 8KiB 6.83M/s 4KiB 2.8M/s 2KiB 1.28M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=3 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.48M/s 2MiB 5.46M/s 1MiB 7.4M/s 512KiB 7.39M/s 256KiB 7.34M/s 128KiB 7.35M/s 64KiB 7.34M/s 32KiB 7.26M/s 16KiB 7.11M/s 8KiB 6.83M/s 4KiB 2.81M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.8M/s 2MiB 5.8M/s 1MiB 7.32M/s 512KiB 5.83M/s 256KiB 7.36M/s 128KiB 7.33M/s 64KiB 7.34M/s
32KiB 7.26M/s 16KiB 7.12M/s 8KiB 6.8M/s 4KiB 2.8M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=5 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.95M/s 2MiB 6.06M/s 1MiB 7.34M/s 512KiB 4.22M/s 256KiB 1.45M/s 128KiB 675K/s ^C
--> 4 open linear AU's?
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 6.86M/s 2MiB 5.81M/s 1MiB 7.33M/s 512KiB 3.39M/s 256KiB 1.39M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 5.44M/s 2MiB 4.88M/s 1MiB 7.34M/s 512KiB 4.45M/s 256KiB 4.95M/s 128KiB 2.7M/s 64KiB 4.98M/s 32KiB 2.88M/s 16KiB 2.85M/s 8KiB 1.65M/s 4KiB 960K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 4.79M/s 2MiB 5.99M/s 1MiB 5.44M/s 512KiB 4.41M/s 256KiB 1.53M/s 128KiB 941K/s 64KiB 540K/s ^C bash-4.1#
--> only 1 open random AU? Or, I got the erasesize wrong, and there are two:
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 7.09M/s 1MiB 2.68M/s 512KiB 7.26M/s 256KiB 3.57M/s 128KiB 4.12M/s 64KiB 3.63M/s 32KiB 2.47M/s 16KiB 2.53M/s 8KiB 2.2M/s 4KiB 960K/s 2KiB 436K/s ^C^[[A bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 5.1M/s 1MiB 7.42M/s 512KiB 4.85M/s 256KiB 4.37M/s 128KiB 2.86M/s 64KiB 6.73M/s 32KiB 2.81M/s 16KiB 2.21M/s 8KiB 1.98M/s 4KiB 866K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=3 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 4.32M/s 1MiB 5.91M/s 512KiB 4.11M/s 256KiB 1.39M/s 128KiB 998K/s 64KiB 619K/s ^C bash-4.1#
bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[4 * 1024*1024] --random --blocksize=512 /dev/sdc 4MiB 3.8M/s 3.59M/s 7.41M/s 7.39M/s 7.37M/s 2MiB 3.54M/s 4.34M/s 5.48M/s 7.37M/s 7.4M/s 1MiB 3.54M/s 4.33M/s 5.5M/s 7.39M/s 7.41M/s 512KiB 4.24M/s 3.33M/s 3.36M/s 4.01M/s 4.44M/s 256KiB 4.24M/s 3.06M/s 2.7M/s 2.71M/s 2.71M/s 128KiB 3.78M/s 2.83M/s 2.72M/s 2.72M/s 2.72M/s 64KiB 2.96M/s 2.72M/s 2.4M/s 2.4M/s 2.4M/s 32KiB 3.23M/s 2.81M/s 2.67M/s 2.67M/s 2.67M/s 16KiB 2.57M/s 2.47M/s 2.47M/s 2.47M/s 2.46M/s 8KiB 1.67M/s 1.87M/s 1.87M/s 1.87M/s 1.87M/s 4KiB 1.03M/s 951K/s 882K/s 814K/s 816K/s 2KiB 464K/s 466K/s 436K/s 411K/s 411K/s ^C bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[2 * 1024*1024] --random --blocksize=512 /dev/sdc 2MiB 4.25M/s 7.07M/s 3.07M/s 4.34M/s 7.39M/s 1MiB 7.11M/s 3.05M/s 3.05M/s 4.41M/s 7.38M/s 512KiB 4.27M/s 3.08M/s 3.03M/s 2.72M/s 3.64M/s 256KiB 4.17M/s 3.54M/s 3.54M/s 2.4M/s 2.39M/s 128KiB 2.95M/s 2.99M/s 2.97M/s 2.73M/s 2.74M/s 64KiB 4.12M/s 2.98M/s 2.98M/s 2.29M/s 2.3M/s 32KiB 2.8M/s 2.21M/s 2.21M/s 2.53M/s 2.54M/s 16KiB 2.6M/s 2.06M/s 2.6M/s 2.58M/s 2.58M/s 8KiB 1.54M/s 1.81M/s 1.82M/s 1.81M/s 1.19M/s 4KiB 1.03M/s 940K/s 791K/s 969K/s 829K/s ^C bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[1 * 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 2.97M/s 3.05M/s 3.1M/s 3.08M/s 3.12M/s 512KiB 3.02M/s 7.04M/s 3.02M/s 3.02M/s 3.03M/s 256KiB 6.95M/s 3.02M/s 6.99M/s 6.93M/s 6.93M/s 128KiB 1.87M/s 2.97M/s 2.98M/s 1.87M/s 1.86M/s 64KiB 6.75M/s 6.79M/s 6.81M/s 2.89M/s 6.84M/s 32KiB 1.33M/s 2.81M/s 2.85M/s 2.83M/s 2.84M/s 16KiB 1.73M/s 2.61M/s 2.63M/s 1.72M/s 2.61M/s 8KiB 1.18M/s 2.23M/s 1.55M/s 2.23M/s 2.22M/s 4KiB 1.04M/s 1.04M/s 866K/s 1.04M/s 1.05M/s 2KiB 504K/s 459K/s 458K/s 504K/s 420K/s ^C bash-4.1#
--> all very unclear to me.
##with the following, I'm trying some offsets to confirm the eraseblock size. I wasn't able to sort anything very useable out of this.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[123*512] 4MiB 3.99M/s 2MiB 3.38M/s 1MiB 4.02M/s 512KiB 3.97M/s 256KiB 3.29M/s 128KiB 3.74M/s 64KiB 2.74M/s 32KiB 2.46M/s 16KiB 1.69M/s 8KiB 1.43M/s 4KiB 756K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[28*1024*1024] 4MiB 5.48M/s 2MiB 7.44M/s 1MiB 7.42M/s 512KiB 3.67M/s 256KiB 4.82M/s 128KiB 2.71M/s 64KiB 5M/s 32KiB 2.89M/s 16KiB 2.86M/s 8KiB 1.66M/s 4KiB 964K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[29*1024*1024] 4MiB 3.76M/s 2MiB 5.46M/s 1MiB 7.36M/s 512KiB 4.86M/s 256KiB 4.82M/s 128KiB 2.71M/s 64KiB 5M/s 32KiB 2.89M/s 16KiB 2.51M/s 8KiB 1.66M/s 4KiB 963K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[30*1024*1024] 4MiB 3.49M/s 2MiB 7.27M/s 1MiB 4.08M/s 512KiB 5.55M/s 256KiB 3.84M/s 128KiB 3.11M/s 64KiB 4.03M/s 32KiB 3.35M/s 16KiB 2.87M/s 8KiB 1.63M/s 4KiB 968K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[57*512*1024] 4MiB 4.02M/s 2MiB 4.6M/s 1MiB 6.33M/s 512KiB 3.18M/s 256KiB 3.48M/s 128KiB 2.23M/s 64KiB 1.33M/s 32KiB 906K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random --offset=$[57*512*1024] 1MiB 3.15M/s 512KiB 7.21M/s 256KiB 6.9M/s 128KiB 1.91M/s 64KiB 6.63M/s 32KiB 6.13M/s 16KiB 1.59M/s 8KiB 3.8M/s 4KiB 950K/s 2KiB 419K/s 1KiB 216K/s bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random --offset=$[61*512*1024] 1MiB 5.3M/s 512KiB 4.38M/s 256KiB 3.04M/s 128KiB 6.81M/s 64KiB 6.64M/s 32KiB 1.6M/s 16KiB 5.12M/s 8KiB 1.38M/s 4KiB 985K/s 2KiB 466K/s 1KiB 221K/s bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random --offset=$[123*256*1024] 1MiB 3.04M/s 512KiB 6.96M/s 256KiB 7.07M/s 128KiB 2.98M/s 64KiB 6.71M/s 32KiB 2.21M/s 16KiB 1.74M/s 8KiB 3.83M/s 4KiB 888K/s 2KiB 389K/s 1KiB 218K/s bash-4.1#
If you have more tests you would like performed, I can do them, once I am either done recovering data or give up on it. I'm very perplexed by this drive, because it was very clear to see the 4MB units in the kingston drive, both with the flashbench -a test and on the scatter plot. I spent the last couple of weeks benchmarking this drive with a script that I wrote, to try out various filesystems that work best with the Porteus operating system. I ran a substantial amount of tests with it improperly aligned, and got only a slight improvement when I aligned it to start partitions on 24MB blocks, so I guess it's not surprising that the eraseblock boundaries are difficult to find!
I am curious to know what kind of improvements you see (or expect to see) when a drive is in versus out of alignment (and I'll be benchmarking my kingston drive to test this out as well). This information will likely be of great interest to our community.
If I can sort out and resolve the cause for my drives getting wasted, I'll also recommend the flashbench tool to other users, and collect their results for your flashcard survey.
Thanks again!
-Ahau
On Tuesday 26 July 2011, Ajax Criterion wrote:
I have three flash drives ( an 8GB Kingston DataTraveller DT101 G2, which doesn't seem to match up with the results you've already posted on the flash card survey for an 8GB DataTraveller, a 4GB Lexar JumpDrive TwistTurn, and an old 1GB USB1.1 unnamed drive that I received as a gift). I benched the Kingston and Lexar models yesterday, but somehow flashbench or one of the other commands I ran during the process wiped out the MBR and partition tables on both drives, and I've lost almost all of my data. The only thing I've been able to salvage so far is the results for the Lexar drive.
As I wrote in my other mail, I'm deeply sorry about that, I should have made it more clear in the documentation that flashbench will in fact overwrite data on the device.
I'll send along results for the others, and if I can figure out what I did to hose my drives I'll report on that as well (if you have any good recommendations for recovering data, I'm all ears! I've tried testdisk, dd_rescue, and scalpel without much luck --this could just be my lack of skill lol. Scalpel was able to get some text scattered around, which is how I got the Lexar results back).
It depends a lot on the file system on it. With ext3 your chances might not be too bad, with FAT32 you have probably overwritten most of the metadata already. Flashbench writes to a few erase blocks at the start of the drive (every sixth erase block in the --open-au test, starting at 16 MB, for n blocks). If you have partitions that are not at the start of the drive, they should be ok if only you can recreate the partition table.
Fortunately you have output the partition table for both sticks, so that is definitely possible. You can use 'fdisk -cu /dev/sdc' to get into the partitioning tool again, and then enter the sector numbers for ech partition the way you had before. If the superblock is still ok, you should be able to run fsck ok the partition.
Ok, on to the results:
## Note -- this drive is 2-3 years old, give or take.
bash-4.1# Bus 002 Device 004: ID 05dc:a764 Lexar Media, Inc.
bash-4.1# fdisk -lu /dev/sdc
Disk /dev/sdc: 4009 MB, 4009754624 bytes 128 heads, 16 sectors/track, 3824 cylinders, total 7831552 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77ac9c58
Device Boot Start End Blocks Id System /dev/sdc1 * 49152 3637247 1794048 83 Linux /dev/sdc2 3637248 7831551 2097152 83 Linux bash-4.1#
## In an effort to improve performance without really knowing the erasesize of this drive, I started my partitions on 24MB intervals (least common denominator for all of the common allocation unit sizes on the flash card survey) and set my cylinder size to be one MB (I don't know if cylinder size, sectors/track, etc., really matters, since the FS block sizes don't match up to the page sizes anyway, but I thought it was worth a try). However, this didn't really help my performance very much. I should note that partition sdc1 was actually formatted as FAT32, and sdc2 was formatted as EXT4.
flashbench will have written mostly to the FAT partition here.
My first recommendation regarding performance is that you should try btrfs on the second partition to replace ext4.
bash-4.1# hdparm -I /dev/sdc
/dev/sdc: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
hdparm only makes sense on CF cards, it doesn't work on USB.
cat /proc/partitions 8 32 3915776 sdc 8 33 1794048 sdc1 8 34 2097152 sdc2
bash-4.1# ./flashbench -a /dev/sdc --blocksize=1024 --count=100 align 1073741824 pre 846µs on 867µs post 849µs diff 19.8µs align 536870912 pre 817µs on 866µs post 815µs diff 49.2µs align 268435456 pre 809µs on 855µs post 811µs diff 45.3µs align 134217728 pre 819µs on 856µs post 794µs diff 49.6µs align 67108864 pre 814µs on 857µs post 808µs diff 45.6µs align 33554432 pre 809µs on 857µs post 806µs diff 49.5µs align 16777216 pre 818µs on 862µs post 813µs diff 46.2µs align 8388608 pre 808µs on 861µs post 805µs diff 54.7µs align 4194304 pre 798µs on 857µs post 804µs diff 56.3µs align 2097152 pre 833µs on 862µs post 814µs diff 38.1µs align 1048576 pre 829µs on 881µs post 818µs diff 57µs align 524288 pre 829µs on 884µs post 826µs diff 56.2µs align 262144 pre 849µs on 886µs post 807µs diff 58.1µs align 131072 pre 849µs on 876µs post 832µs diff 35.8µs align 65536 pre 837µs on 884µs post 824µs diff 53.7µs align 32768 pre 824µs on 883µs post 831µs diff 55µs align 16384 pre 833µs on 881µs post 833µs diff 48.7µs align 8192 pre 832µs on 875µs post 820µs diff 48.6µs align 4096 pre 827µs on 880µs post 831µs diff 51.4µs align 2048 pre 833µs on 821µs post 831µs diff -11049n bash-4.1#
##I wasn't sure, but I assumed that this means I have a 4MB erase block -- my numbers were even more inconsistent before I added the count=100 option. I also made a number of scatter plots for this drive, with and without offsets to different locations on the drive, and it showed a straight line for 24+MB (whereas my kingston drive showed very clear jumps at 4MB intervals).
Ok. 24 MB sounds like a really high number for a 4 GB drive, especially when it's so slow.
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.8M/s 2MiB 5.8M/s 1MiB 7.32M/s 512KiB 5.83M/s 256KiB 7.36M/s 128KiB 7.33M/s 64KiB 7.34M/s
32KiB 7.26M/s 16KiB 7.12M/s 8KiB 6.8M/s 4KiB 2.8M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=5 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.95M/s 2MiB 6.06M/s 1MiB 7.34M/s 512KiB 4.22M/s 256KiB 1.45M/s 128KiB 675K/s ^C
--> 4 open linear AU's?
Yes, exactly. However, the fact that 1MB and 4MB blocksize gives you the same performance would indicate 1MB erase blocks, which is much more common for 4GB drives. If you bought this one before 2010, it's almost certainly 1MB erase block with five concurrently open erase blocks.
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 6.86M/s 2MiB 5.81M/s 1MiB 7.33M/s 512KiB 3.39M/s 256KiB 1.39M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 5.44M/s 2MiB 4.88M/s 1MiB 7.34M/s 512KiB 4.45M/s 256KiB 4.95M/s 128KiB 2.7M/s 64KiB 4.98M/s 32KiB 2.88M/s 16KiB 2.85M/s 8KiB 1.65M/s 4KiB 960K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 4.79M/s 2MiB 5.99M/s 1MiB 5.44M/s 512KiB 4.41M/s 256KiB 1.53M/s 128KiB 941K/s 64KiB 540K/s ^C bash-4.1#
--> only 1 open random AU? Or, I got the erasesize wrong, and there are two:
Yes, since the stick can only have 4*1MB open, trying to write to 2*4MB will not be efficient. This only shows up in the --random test, because in case of linear writes, it always completes writing each of the four 1MB blocks before starting the next one.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 7.09M/s 1MiB 2.68M/s 512KiB 7.26M/s 256KiB 3.57M/s 128KiB 4.12M/s 64KiB 3.63M/s 32KiB 2.47M/s 16KiB 2.53M/s 8KiB 2.2M/s 4KiB 960K/s 2KiB 436K/s ^C^[[A bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 5.1M/s 1MiB 7.42M/s 512KiB 4.85M/s 256KiB 4.37M/s 128KiB 2.86M/s 64KiB 6.73M/s 32KiB 2.81M/s 16KiB 2.21M/s 8KiB 1.98M/s 4KiB 866K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=3 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 4.32M/s 1MiB 5.91M/s 512KiB 4.11M/s 256KiB 1.39M/s 128KiB 998K/s 64KiB 619K/s ^C
Yes, absolutely consistent.
bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[4 * 1024*1024] --random --blocksize=512 /dev/sdc 4MiB 3.8M/s 3.59M/s 7.41M/s 7.39M/s 7.37M/s 2MiB 3.54M/s 4.34M/s 5.48M/s 7.37M/s 7.4M/s 1MiB 3.54M/s 4.33M/s 5.5M/s 7.39M/s 7.41M/s 512KiB 4.24M/s 3.33M/s 3.36M/s 4.01M/s 4.44M/s 256KiB 4.24M/s 3.06M/s 2.7M/s 2.71M/s 2.71M/s 128KiB 3.78M/s 2.83M/s 2.72M/s 2.72M/s 2.72M/s 64KiB 2.96M/s 2.72M/s 2.4M/s 2.4M/s 2.4M/s 32KiB 3.23M/s 2.81M/s 2.67M/s 2.67M/s 2.67M/s 16KiB 2.57M/s 2.47M/s 2.47M/s 2.47M/s 2.46M/s 8KiB 1.67M/s 1.87M/s 1.87M/s 1.87M/s 1.87M/s 4KiB 1.03M/s 951K/s 882K/s 814K/s 816K/s 2KiB 464K/s 466K/s 436K/s 411K/s 411K/s ^C bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[2 * 1024*1024] --random --blocksize=512 /dev/sdc 2MiB 4.25M/s 7.07M/s 3.07M/s 4.34M/s 7.39M/s 1MiB 7.11M/s 3.05M/s 3.05M/s 4.41M/s 7.38M/s 512KiB 4.27M/s 3.08M/s 3.03M/s 2.72M/s 3.64M/s 256KiB 4.17M/s 3.54M/s 3.54M/s 2.4M/s 2.39M/s 128KiB 2.95M/s 2.99M/s 2.97M/s 2.73M/s 2.74M/s 64KiB 4.12M/s 2.98M/s 2.98M/s 2.29M/s 2.3M/s 32KiB 2.8M/s 2.21M/s 2.21M/s 2.53M/s 2.54M/s 16KiB 2.6M/s 2.06M/s 2.6M/s 2.58M/s 2.58M/s 8KiB 1.54M/s 1.81M/s 1.82M/s 1.81M/s 1.19M/s 4KiB 1.03M/s 940K/s 791K/s 969K/s 829K/s ^C bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[1 * 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 2.97M/s 3.05M/s 3.1M/s 3.08M/s 3.12M/s 512KiB 3.02M/s 7.04M/s 3.02M/s 3.02M/s 3.03M/s 256KiB 6.95M/s 3.02M/s 6.99M/s 6.93M/s 6.93M/s 128KiB 1.87M/s 2.97M/s 2.98M/s 1.87M/s 1.86M/s 64KiB 6.75M/s 6.79M/s 6.81M/s 2.89M/s 6.84M/s 32KiB 1.33M/s 2.81M/s 2.85M/s 2.83M/s 2.84M/s 16KiB 1.73M/s 2.61M/s 2.63M/s 1.72M/s 2.61M/s 8KiB 1.18M/s 2.23M/s 1.55M/s 2.23M/s 2.22M/s 4KiB 1.04M/s 1.04M/s 866K/s 1.04M/s 1.05M/s 2KiB 504K/s 459K/s 458K/s 504K/s 420K/s ^C bash-4.1#
--> all very unclear to me.
Yes, these are not clear. Best repeat the 1MB findfat test with --fat-nr=10, because the first test suggests that there might be a FAT area in the first 8 MB.
##with the following, I'm trying some offsets to confirm the eraseblock size. I wasn't able to sort anything very useable out of this.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[123*512] 4MiB 3.99M/s 2MiB 3.38M/s 1MiB 4.02M/s 512KiB 3.97M/s 256KiB 3.29M/s 128KiB 3.74M/s 64KiB 2.74M/s 32KiB 2.46M/s 16KiB 1.69M/s 8KiB 1.43M/s 4KiB 756K/s ^C
consistently slow, as expected with an odd sector offset.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[28*1024*1024] 4MiB 5.48M/s 2MiB 7.44M/s 1MiB 7.42M/s 512KiB 3.67M/s 256KiB 4.82M/s 128KiB 2.71M/s 64KiB 5M/s 32KiB 2.89M/s 16KiB 2.86M/s 8KiB 1.66M/s 4KiB 964K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[29*1024*1024] 4MiB 3.76M/s 2MiB 5.46M/s 1MiB 7.36M/s 512KiB 4.86M/s 256KiB 4.82M/s 128KiB 2.71M/s 64KiB 5M/s 32KiB 2.89M/s 16KiB 2.51M/s 8KiB 1.66M/s 4KiB 963K/s ^C
These are both multiples of 1 MB and are relatively fast. I don't know why it fluctuates in the 128KB line, but it seems to be relatively consistent. The first line in the second test is slow because it starts with a garbage collected from the interrupted run.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random --offset=$[57*512*1024] 1MiB 3.15M/s 512KiB 7.21M/s 256KiB 6.9M/s 128KiB 1.91M/s 64KiB 6.63M/s 32KiB 6.13M/s 16KiB 1.59M/s 8KiB 3.8M/s 4KiB 950K/s 2KiB 419K/s 1KiB 216K/s
Here it's very clear that it garbage collects in the 128KB and 16KB lines, which is what happens when you misalign by half an erase block.
If you have more tests you would like performed, I can do them, once I am either done recovering data or give up on it. I'm very perplexed by this drive, because it was very clear to see the 4MB units in the kingston drive, both with the flashbench -a test and on the scatter plot. I spent the last couple of weeks benchmarking this drive with a script that I wrote, to try out various filesystems that work best with the Porteus operating system. I ran a substantial amount of tests with it improperly aligned, and got only a slight improvement when I aligned it to start partitions on 24MB blocks, so I guess it's not surprising that the eraseblock boundaries are difficult to find!
Finding the correct erase block sizes takes a lot of experience, yes.
I am curious to know what kind of improvements you see (or expect to see) when a drive is in versus out of alignment (and I'll be benchmarking my kingston drive to test this out as well). This information will likely be of great interest to our community.
If I can sort out and resolve the cause for my drives getting wasted, I'll also recommend the flashbench tool to other users, and collect their results for your flashcard survey.
flashbench is currently too hard to use and too dangerous for many users (sorry again). It doesn't destroy your drive unless you let it run for days with the worst possible setting, but it does overwrite your data in the write tests.
Arnd
On Wed, Jul 27, 2011 at 10:04 AM, Arnd Bergmann arnd@arndb.de wrote:
On Tuesday 26 July 2011, Ajax Criterion wrote:
I have three flash drives ( an 8GB Kingston DataTraveller DT101 G2, which doesn't seem to match up with the results you've already posted on the flash card survey for an 8GB DataTraveller, a 4GB Lexar JumpDrive TwistTurn, and an old 1GB USB1.1 unnamed drive that I received as a gift). I benched the Kingston and Lexar models yesterday, but somehow flashbench or one of the other commands I ran during the process wiped out the MBR and partition tables on both drives, and I've lost almost all of my data. The only thing I've been able to salvage so far is the results for the Lexar drive.
As I wrote in my other mail, I'm deeply sorry about that, I should have made it more clear in the documentation that flashbench will in fact overwrite data on the device.
I'll send along results for the others, and if I can figure out what I did to hose my drives I'll report on that as well (if you have any good recommendations for recovering data, I'm all ears! I've tried testdisk, dd_rescue, and scalpel without much luck --this could just be my lack of skill lol. Scalpel was able to get some text scattered around, which is how I got the Lexar results back).
It depends a lot on the file system on it. With ext3 your chances might not be too bad, with FAT32 you have probably overwritten most of the metadata already. Flashbench writes to a few erase blocks at the start of the drive (every sixth erase block in the --open-au test, starting at 16 MB, for n blocks). If you have partitions that are not at the start of the drive, they should be ok if only you can recreate the partition table.
Fortunately you have output the partition table for both sticks, so that is definitely possible. You can use 'fdisk -cu /dev/sdc' to get into the partitioning tool again, and then enter the sector numbers for ech partition the way you had before. If the superblock is still ok, you should be able to run fsck ok the partition.
Ok, on to the results:
## Note -- this drive is 2-3 years old, give or take.
bash-4.1# Bus 002 Device 004: ID 05dc:a764 Lexar Media, Inc.
bash-4.1# fdisk -lu /dev/sdc
Disk /dev/sdc: 4009 MB, 4009754624 bytes 128 heads, 16 sectors/track, 3824 cylinders, total 7831552 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x77ac9c58
Device Boot Start End Blocks Id System /dev/sdc1 * 49152 3637247 1794048 83 Linux /dev/sdc2 3637248 7831551 2097152 83 Linux bash-4.1#
## In an effort to improve performance without really knowing the erasesize of this drive, I started my partitions on 24MB intervals (least common denominator for all of the common allocation unit sizes on the flash card survey) and set my cylinder size to be one MB (I don't know if cylinder size, sectors/track, etc., really matters, since the FS block sizes don't match up to the page sizes anyway, but I thought it was worth a try). However, this didn't really help my performance very much. I should note that partition sdc1 was actually formatted as FAT32, and sdc2 was formatted as EXT4.
flashbench will have written mostly to the FAT partition here.
My first recommendation regarding performance is that you should try btrfs on the second partition to replace ext4.
bash-4.1# hdparm -I /dev/sdc
/dev/sdc: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
hdparm only makes sense on CF cards, it doesn't work on USB.
cat /proc/partitions 8 32 3915776 sdc 8 33 1794048 sdc1 8 34 2097152 sdc2
bash-4.1# ./flashbench -a /dev/sdc --blocksize=1024 --count=100 align 1073741824 pre 846碌s on 867碌s post 849碌s diff 19.8碌s align 536870912 pre 817碌s on 866碌s post 815碌s diff 49.2碌s align 268435456 pre 809碌s on 855碌s post 811碌s diff 45.3碌s align 134217728 pre 819碌s on 856碌s post 794碌s diff 49.6碌s align 67108864 pre 814碌s on 857碌s post 808碌s diff 45.6碌s align 33554432 pre 809碌s on 857碌s post 806碌s diff 49.5碌s align 16777216 pre 818碌s on 862碌s post 813碌s diff 46.2碌s align 8388608 pre 808碌s on 861碌s post 805碌s diff 54.7碌s align 4194304 pre 798碌s on 857碌s post 804碌s diff 56.3碌s align 2097152 pre 833碌s on 862碌s post 814碌s diff 38.1碌s align 1048576 pre 829碌s on 881碌s post 818碌s diff 57碌s align 524288 pre 829碌s on 884碌s post 826碌s diff 56.2碌s align 262144 pre 849碌s on 886碌s post 807碌s diff 58.1碌s align 131072 pre 849碌s on 876碌s post 832碌s diff 35.8碌s align 65536 pre 837碌s on 884碌s post 824碌s diff 53.7碌s align 32768 pre 824碌s on 883碌s post 831碌s diff 55碌s align 16384 pre 833碌s on 881碌s post 833碌s diff 48.7碌s align 8192 pre 832碌s on 875碌s post 820碌s diff 48.6碌s align 4096 pre 827碌s on 880碌s post 831碌s diff 51.4碌s align 2048 pre 833碌s on 821碌s post 831碌s diff -11049n bash-4.1#
##I wasn't sure, but I assumed that this means I have a 4MB erase block -- my numbers were even more inconsistent before I added the count=100 option. I also made a number of scatter plots for this drive, with and without offsets to different locations on the drive, and it showed a straight line for 24+MB (whereas my kingston drive showed very clear jumps at 4MB intervals).
Ok. 24 MB sounds like a really high number for a 4 GB drive, especially when it's so slow.
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.8M/s 2MiB 5.8M/s 1MiB 7.32M/s 512KiB 5.83M/s 256KiB 7.36M/s 128KiB 7.33M/s 64KiB 7.34M/s
32KiB 7.26M/s 16KiB 7.12M/s 8KiB 6.8M/s 4KiB 2.8M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=5 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 4MiB 6.95M/s 2MiB 6.06M/s 1MiB 7.34M/s 512KiB 4.22M/s 256KiB 1.45M/s 128KiB 675K/s ^C
--> 4 open linear AU's?
Yes, exactly. However, the fact that 1MB and 4MB blocksize gives you the same performance would indicate 1MB erase blocks, which is much more common for 4GB drives. If you bought this one before 2010, it's almost certainly 1MB erase block with five concurrently open erase blocks.
bash-4.1# ./flashbench --open-au --open-au-nr=4 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 6.86M/s 2MiB 5.81M/s 1MiB 7.33M/s 512KiB 3.39M/s 256KiB 1.39M/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 5.44M/s 2MiB 4.88M/s 1MiB 7.34M/s 512KiB 4.45M/s 256KiB 4.95M/s 128KiB 2.7M/s 64KiB 4.98M/s 32KiB 2.88M/s 16KiB 2.85M/s 8KiB 1.65M/s 4KiB 960K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random 4MiB 4.79M/s 2MiB 5.99M/s 1MiB 5.44M/s 512KiB 4.41M/s 256KiB 1.53M/s 128KiB 941K/s 64KiB 540K/s ^C bash-4.1#
--> only 1 open random AU? Or, I got the erasesize wrong, and there are two:
Yes, since the stick can only have 4*1MB open, trying to write to 2*4MB will not be efficient. This only shows up in the --random test, because in case of linear writes, it always completes writing each of the four 1MB blocks before starting the next one.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 7.09M/s 1MiB 2.68M/s 512KiB 7.26M/s 256KiB 3.57M/s 128KiB 4.12M/s 64KiB 3.63M/s 32KiB 2.47M/s 16KiB 2.53M/s 8KiB 2.2M/s 4KiB 960K/s 2KiB 436K/s ^C^[[A bash-4.1# ./flashbench --open-au --open-au-nr=2 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 5.1M/s 1MiB 7.42M/s 512KiB 4.85M/s 256KiB 4.37M/s 128KiB 2.86M/s 64KiB 6.73M/s 32KiB 2.81M/s 16KiB 2.21M/s 8KiB 1.98M/s 4KiB 866K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=3 /dev/sdc --erasesize=$[2 * 1024 * 1024] --blocksize=1024 --random 2MiB 4.32M/s 1MiB 5.91M/s 512KiB 4.11M/s 256KiB 1.39M/s 128KiB 998K/s 64KiB 619K/s ^C
Yes, absolutely consistent.
bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[4 * 1024*1024] --random --blocksize=512 /dev/sdc 4MiB 3.8M/s 3.59M/s 7.41M/s 7.39M/s 7.37M/s 2MiB 3.54M/s 4.34M/s 5.48M/s 7.37M/s 7.4M/s 1MiB 3.54M/s 4.33M/s 5.5M/s 7.39M/s 7.41M/s 512KiB 4.24M/s 3.33M/s 3.36M/s 4.01M/s 4.44M/s 256KiB 4.24M/s 3.06M/s 2.7M/s 2.71M/s 2.71M/s 128KiB 3.78M/s 2.83M/s 2.72M/s 2.72M/s 2.72M/s 64KiB 2.96M/s 2.72M/s 2.4M/s 2.4M/s 2.4M/s 32KiB 3.23M/s 2.81M/s 2.67M/s 2.67M/s 2.67M/s 16KiB 2.57M/s 2.47M/s 2.47M/s 2.47M/s 2.46M/s 8KiB 1.67M/s 1.87M/s 1.87M/s 1.87M/s 1.87M/s 4KiB 1.03M/s 951K/s 882K/s 814K/s 816K/s 2KiB 464K/s 466K/s 436K/s 411K/s 411K/s ^C bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[2 * 1024*1024] --random --blocksize=512 /dev/sdc 2MiB 4.25M/s 7.07M/s 3.07M/s 4.34M/s 7.39M/s 1MiB 7.11M/s 3.05M/s 3.05M/s 4.41M/s 7.38M/s 512KiB 4.27M/s 3.08M/s 3.03M/s 2.72M/s 3.64M/s 256KiB 4.17M/s 3.54M/s 3.54M/s 2.4M/s 2.39M/s 128KiB 2.95M/s 2.99M/s 2.97M/s 2.73M/s 2.74M/s 64KiB 4.12M/s 2.98M/s 2.98M/s 2.29M/s 2.3M/s 32KiB 2.8M/s 2.21M/s 2.21M/s 2.53M/s 2.54M/s 16KiB 2.6M/s 2.06M/s 2.6M/s 2.58M/s 2.58M/s 8KiB 1.54M/s 1.81M/s 1.82M/s 1.81M/s 1.19M/s 4KiB 1.03M/s 940K/s 791K/s 969K/s 829K/s ^C bash-4.1# ./flashbench --findfat --fat-nr=5 --erasesize=$[1 * 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 2.97M/s 3.05M/s 3.1M/s 3.08M/s 3.12M/s 512KiB 3.02M/s 7.04M/s 3.02M/s 3.02M/s 3.03M/s 256KiB 6.95M/s 3.02M/s 6.99M/s 6.93M/s 6.93M/s 128KiB 1.87M/s 2.97M/s 2.98M/s 1.87M/s 1.86M/s 64KiB 6.75M/s 6.79M/s 6.81M/s 2.89M/s 6.84M/s 32KiB 1.33M/s 2.81M/s 2.85M/s 2.83M/s 2.84M/s 16KiB 1.73M/s 2.61M/s 2.63M/s 1.72M/s 2.61M/s 8KiB 1.18M/s 2.23M/s 1.55M/s 2.23M/s 2.22M/s 4KiB 1.04M/s 1.04M/s 866K/s 1.04M/s 1.05M/s 2KiB 504K/s 459K/s 458K/s 504K/s 420K/s ^C bash-4.1#
--> all very unclear to me.
Yes, these are not clear. Best repeat the 1MB findfat test with --fat-nr=10, because the first test suggests that there might be a FAT area in the first 8 MB.
##with the following, I'm trying some offsets to confirm the eraseblock size. I wasn't able to sort anything very useable out of this.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[123*512] 4MiB 3.99M/s 2MiB 3.38M/s 1MiB 4.02M/s 512KiB 3.97M/s 256KiB 3.29M/s 128KiB 3.74M/s 64KiB 2.74M/s 32KiB 2.46M/s 16KiB 1.69M/s 8KiB 1.43M/s 4KiB 756K/s ^C
consistently slow, as expected with an odd sector offset.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[28*1024*1024] 4MiB 5.48M/s 2MiB 7.44M/s 1MiB 7.42M/s 512KiB 3.67M/s 256KiB 4.82M/s 128KiB 2.71M/s 64KiB 5M/s 32KiB 2.89M/s 16KiB 2.86M/s 8KiB 1.66M/s 4KiB 964K/s ^C bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[4 * 1024 * 1024] --blocksize=1024 --random --offset=$[29*1024*1024] 4MiB 3.76M/s 2MiB 5.46M/s 1MiB 7.36M/s 512KiB 4.86M/s 256KiB 4.82M/s 128KiB 2.71M/s 64KiB 5M/s 32KiB 2.89M/s 16KiB 2.51M/s 8KiB 1.66M/s 4KiB 963K/s ^C
These are both multiples of 1 MB and are relatively fast. I don't know why it fluctuates in the 128KB line, but it seems to be relatively consistent. The first line in the second test is slow because it starts with a garbage collected from the interrupted run.
bash-4.1# ./flashbench --open-au --open-au-nr=1 /dev/sdc --erasesize=$[1 * 1024 * 1024] --blocksize=1024 --random --offset=$[57*512*1024] 1MiB 3.15M/s 512KiB 7.21M/s 256KiB 6.9M/s 128KiB 1.91M/s 64KiB 6.63M/s 32KiB 6.13M/s 16KiB 1.59M/s 8KiB 3.8M/s 4KiB 950K/s 2KiB 419K/s 1KiB 216K/s
Here it's very clear that it garbage collects in the 128KB and 16KB lines, which is what happens when you misalign by half an erase block.
If you have more tests you would like performed, I can do them, once I am either done recovering data or give up on it. I'm very perplexed by this drive, because it was very clear to see the 4MB units in the kingston drive, both with the flashbench -a test and on the scatter plot. I spent the last couple of weeks benchmarking this drive with a script that I wrote, to try out various filesystems that work best with the Porteus operating system. I ran a substantial amount of tests with it improperly aligned, and got only a slight improvement when I aligned it to start partitions on 24MB blocks, so I guess it's not surprising that the eraseblock boundaries are difficult to find!
Finding the correct erase block sizes takes a lot of experience, yes.
I am curious to know what kind of improvements you see (or expect to see) when a drive is in versus out of alignment (and I'll be benchmarking my kingston drive to test this out as well). This information will likely be of great interest to our community.
If I can sort out and resolve the cause for my drives getting wasted, I'll also recommend the flashbench tool to other users, and collect their results for your flashcard survey.
flashbench is currently too hard to use and too dangerous for many users (sorry again). It doesn't destroy your drive unless you let it run for days with the worst possible setting, but it does overwrite your data in the write tests.
Arnd
Thanks! By 'wasting my drive', I meant erasing my data, not damaging the drive (sorry for using the wrong expression there). Trust me, I have put this Lexar drive through hell for the last two weeks, and it has not been at the hands of flashbench!
Here are some more tests for the Lexar drive, which confirm that it has a 1MB eraseblock size:
bash-4.1# for i in 1 2 3 4 6 8 9 10 11 12 13 ; do echo Size $[$i * 512 * 1024]; flashbench --erasesize=$[$i * 512 * 1024] --blocksize=$[$i * 512 * 1024] --open-au --open-au-nr=10 /dev/sdc; echo Size $[$i * 512 * 1024], offset $[$i * 256 * 1024]; flashbench --erasesize=$[$i * 512 * 1024] --blocksize=$[$i * 512 * 1024] --open-au --open-au-nr=10 --offset=$[$i * 256 * 1024] /dev/sdc; done Size 524288 512KiB 2.65M/s Size 524288, offset 262144 512KiB 2.6M/s Size 1048576 1MiB 6.84M/s Size 1048576, offset 524288 1MiB 3.08M/s Size 1572864 1.5MiB 4.92M/s Size 1572864, offset 786432 1.5MiB 2.93M/s Size 2097152 2MiB 6.93M/s Size 2097152, offset 1048576 2MiB 6.86M/s Size 3145728 3MiB 7.39M/s Size 3145728, offset 1572864 3MiB 4.77M/s Size 4194304 4MiB 7.14M/s Size 4194304, offset 2097152 4MiB 6.88M/s Size 4718592 4.5MiB 6.11M/s Size 4718592, offset 2359296 4.5MiB 6M/s Size 5242880 5MiB 7.19M/s Size 5242880, offset 2621440 5MiB 5.54M/s Size 5767168 5.5MiB 6.42M/s Size 5767168, offset 2883584 5.5MiB 4.99M/s Size 6291456 6MiB 7.21M/s Size 6291456, offset 3145728 6MiB 6.92M/s Size 6815744 6.5MiB 6.69M/s Size 6815744, offset 3407872 6.5MiB 6.38M/s bash-4.1#
---> Pretty clear from this that there is a 1MB erase size, as you suggested.
Repeating the -a test, assuming 1MB erase size:
bash-4.1# flashbench -a /dev/sdc --blocksize=1024 --erasesize=$[1024*1024] --count=100 align 1073741824 pre 756µs on 854µs post 735µs diff 108µs align 536870912 pre 755µs on 845µs post 735µs diff 99.8µs align 268435456 pre 753µs on 855µs post 736µs diff 111µs align 134217728 pre 777µs on 856µs post 735µs diff 99.5µs align 67108864 pre 791µs on 855µs post 742µs diff 87.8µs align 33554432 pre 774µs on 857µs post 743µs diff 98.4µs align 16777216 pre 785µs on 851µs post 742µs diff 86.9µs align 8388608 pre 779µs on 854µs post 743µs diff 93.7µs align 4194304 pre 763µs on 869µs post 752µs diff 111µs align 2097152 pre 766µs on 854µs post 737µs diff 102µs align 1048576 pre 780µs on 873µs post 736µs diff 115µs align 524288 pre 780µs on 850µs post 771µs diff 74.7µs align 262144 pre 793µs on 846µs post 772µs diff 63.5µs align 131072 pre 789µs on 876µs post 775µs diff 94.1µs align 65536 pre 783µs on 874µs post 757µs diff 104µs align 32768 pre 791µs on 876µs post 775µs diff 93.3µs align 16384 pre 789µs on 857µs post 791µs diff 67.6µs align 8192 pre 789µs on 861µs post 790µs diff 71.8µs align 4096 pre 775µs on 857µs post 775µs diff 81.5µs align 2048 pre 803µs on 797µs post 805µs diff -6710ns bash-4.1#
-----> A little more clear this time.
bash-4.1# flashbench -O --open-au-nr=1 /dev/sdc --erasesize=$[1024*1024] --blocksize=1024 1MiB 3.12M/s 512KiB 7.42M/s 256KiB 7.36M/s 128KiB 7.27M/s 64KiB 7.28M/s 32KiB 7.24M/s 16KiB 7.07M/s 8KiB 6.77M/s 4KiB 2.82M/s 2KiB 1.28M/s 1KiB 619K/s bash-4.1# flashbench -O --open-au-nr=5 /dev/sdc --erasesize=$[1024*1024] --blocksize=1024 1MiB 7.38M/s 512KiB 3.4M/s 256KiB 1.73M/s 128KiB 675K/s 64KiB 339K/s ^C bash-4.1# flashbench -O --open-au-nr=4 /dev/sdc --erasesize=$[1024*1024] --blocksize=1024 1MiB 6.23M/s 512KiB 3.41M/s 256KiB 7.39M/s 128KiB 7.37M/s 64KiB 7.31M/s 32KiB 7.24M/s 16KiB 7.17M/s 8KiB 6.84M/s 4KiB 2.81M/s 2KiB 1.28M/s 1KiB 618K/s bash-4.1# flashbench -O --open-au-nr=1 /dev/sdc --erasesize=$[1024*1024] --blocksize=1024 --random 1MiB 7.47M/s 512KiB 4.55M/s 256KiB 7.16M/s 128KiB 2.78M/s 64KiB 6.77M/s 32KiB 2.86M/s 16KiB 1.99M/s 8KiB 2.22M/s 4KiB 972K/s 2KiB 399K/s 1KiB 202K/s bash-4.1# flashbench -O --open-au-nr=4 /dev/sdc --erasesize=$[1024*1024] --blocksize=1024 --random 1MiB 7.37M/s 512KiB 3.97M/s 256KiB 7.15M/s 128KiB 2.77M/s 64KiB 6.76M/s 32KiB 2.81M/s 16KiB 1.97M/s 8KiB 2.19M/s 4KiB 953K/s 2KiB 393K/s 1KiB 200K/s bash-4.1# flashbench -O --open-au-nr=5 /dev/sdc --erasesize=$[1024*1024] --blocksize=1024 --random 1MiB 5.75M/s 512KiB 3.23M/s 256KiB 1.45M/s 128KiB 685K/s 64KiB 340K/s 32KiB 170K/s 16KiB 85.2K/s ^C
----> Very clearly 4 open AU's is the threshold for linear and for random.
A repeat of the 1MB -f test, per your request:
bash-4.1# flashbench --findfat --fat-nr=10 --erasesize=$[1* 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 7.06M/s 3.48M/s 3.31M/s 3.32M/s 3.3M/s 3.06M/s 3.07M/s 7.29M/s 7.33M/s 7.43M/s 512KiB 3.03M/s 7.25M/s 3.05M/s 3.03M/s 3.04M/s 3.04M/s 2.42M/s 2.42M/s 2.43M/s 2.42M/s 256KiB 6.85M/s 4.27M/s 4.23M/s 4.25M/s 4.26M/s 3.05M/s 2.4M/s 2.41M/s 2.4M/s 2.41M/s 128KiB 2.96M/s 2.97M/s 2.95M/s 2.99M/s 2.97M/s 2.98M/s 2.99M/s 2.96M/s 2.97M/s 2.98M/s 64KiB 2.96M/s 2.98M/s 2.94M/s 2.97M/s 2.96M/s 2.99M/s 2.2M/s 2.19M/s 2.17M/s 2.2M/s 32KiB 6.05M/s 2.81M/s 2.83M/s 2.82M/s 2.81M/s 2.83M/s 2.83M/s 2.83M/s 2.83M/s 2.81M/s 16KiB 2.58M/s 2.59M/s 2.61M/s 2.6M/s 2.6M/s 2.61M/s 2.62M/s 2.6M/s 2.62M/s 2.59M/s 8KiB 2.2M/s 1.58M/s 2.2M/s 2.23M/s 2.24M/s 2.25M/s 2.22M/s 1.31M/s 1.34M/s 1.33M/s 4KiB 1.05M/s 1.05M/s 1.05M/s 1.05M/s 1.04M/s 1.05M/s 915K/s 792K/s 788K/s 791K/s 2KiB 506K/s 462K/s 504K/s 505K/s 461K/s 505K/s 465K/s 466K/s 467K/s 393K/s 1KiB 248K/s 237K/s 248K/s 226K/s 237K/s 237K/s 242K/s 188K/s 181K/s 169K/s ^C bash-4.1#
--> not crystal clear for me, though something looks askew in the first 7 columns. repeating:
bash-4.1# flashbench --findfat --fat-nr=10 --erasesize=$[1* 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 3.03M/s 2.99M/s 3.11M/s 3.12M/s 3.11M/s 1.9M/s 1.95M/s 7.42M/s 7.39M/s 3.01M/s 512KiB 7.24M/s 7.2M/s 3.04M/s 3.04M/s 3.03M/s 1.89M/s 2.41M/s 2.44M/s 2.43M/s 1.64M/s 256KiB 3M/s 4.26M/s 2.31M/s 4.26M/s 4.26M/s 3.01M/s 2.41M/s 2.4M/s 1.63M/s 2.42M/s 128KiB 6.8M/s 2.97M/s 3M/s 2.98M/s 2.98M/s 1.87M/s 2.98M/s 2.98M/s 2.98M/s 1.87M/s 64KiB 2.96M/s 2.99M/s 1.88M/s 2.99M/s 3M/s 1.88M/s 2.19M/s 2.18M/s 2.19M/s 2.18M/s 32KiB 6.07M/s 2.83M/s 2.85M/s 2.84M/s 2.85M/s 2.83M/s 2.84M/s 1.35M/s 2.82M/s 2.82M/s 16KiB 2.61M/s 2.6M/s 2.61M/s 2.6M/s 2.62M/s 2.61M/s 2.59M/s 1.73M/s 2.61M/s 1.71M/s 8KiB 2.23M/s 1.56M/s 2.24M/s 2.24M/s 2.23M/s 2.24M/s 2.25M/s 1.34M/s 1.33M/s 1.07M/s 4KiB 1.04M/s 1.05M/s 866K/s 1.05M/s 869K/s 1.04M/s 919K/s 793K/s 791K/s 793K/s 2KiB 508K/s 391K/s 460K/s 506K/s 461K/s 507K/s 426K/s 468K/s 467K/s 467K/s 1KiB 248K/s 238K/s 248K/s 249K/s 248K/s 249K/s 230K/s 202K/s 202K/s 202K/s ^C bash-4.1#
and again:
bash-4.1# flashbench --findfat --fat-nr=10 --erasesize=$[1* 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 3.04M/s 7.3M/s 3.11M/s 3.11M/s 3.11M/s 3.07M/s 3.07M/s 7.36M/s 7.41M/s 7.35M/s 512KiB 7.04M/s 7.19M/s 3.04M/s 3.05M/s 3.05M/s 3.05M/s 2.43M/s 2.44M/s 2.42M/s 2.44M/s 256KiB 2.99M/s 4.29M/s 4.29M/s 4.29M/s 4.28M/s 3.02M/s 2.4M/s 2.41M/s 2.4M/s 2.39M/s 128KiB 6.85M/s 2.97M/s 3.01M/s 2.94M/s 2.96M/s 2.96M/s 2.96M/s 2.98M/s 2.97M/s 2.99M/s 64KiB 2.96M/s 2.97M/s 2.98M/s 2.98M/s 2.97M/s 2.99M/s 2.2M/s 2.21M/s 2.19M/s 2.19M/s 32KiB 6.04M/s 2.81M/s 2.82M/s 2.84M/s 2.83M/s 2.84M/s 2.83M/s 2.85M/s 2.85M/s 2.85M/s 16KiB 2.61M/s 2.62M/s 2.62M/s 2.61M/s 2.6M/s 2.62M/s 2.62M/s 2.61M/s 2.62M/s 2.62M/s 8KiB 2.24M/s 1.57M/s 2.24M/s 2.23M/s 2.23M/s 2.25M/s 2.22M/s 1.33M/s 1.35M/s 1.35M/s 4KiB 1.04M/s 1.05M/s 1.05M/s 1.05M/s 1.05M/s 1.05M/s 916K/s 791K/s 794K/s 794K/s 2KiB 507K/s 463K/s 507K/s 506K/s 506K/s 506K/s 465K/s 468K/s 467K/s 467K/s ^C bash-4.1#
--> Ok, I'm assuming an 8KB page size, and an optimized FAT area -- the question I have is, where does it end? The first MB is clearly optimized at 32K and 128K, but nothing is uniform over the first 8MB.
Increasing to fat-nr=15 to see if eraseblocks 11-15 match 8-10:
bash-4.1# flashbench --findfat --fat-nr=15 --erasesize=$[1* 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 3.04M/s 7.38M/s 3.06M/s 3.06M/s 3.06M/s 3.07M/s 3.05M/s 7.47M/s 7.46M/s 7.45M/s 7.42M/s 7.39M/s 7.39M/s 7.35M/s 7.46M/s 512KiB 7.09M/s 7.24M/s 3.04M/s 3.05M/s 3.07M/s 3.04M/s 2.41M/s 2.43M/s 2.42M/s 2.44M/s 3.16M/s 3.18M/s 3.18M/s 3.16M/s 3.16M/s 256KiB 3.01M/s 4.28M/s 4.27M/s 4.28M/s 4.28M/s 3.01M/s 2.39M/s 2.4M/s 2.41M/s 2.42M/s 2.4M/s 2.4M/s 2.4M/s 2.42M/s 2.41M/s 128KiB 6.76M/s 2.98M/s 3M/s 2.99M/s 2.97M/s 2.97M/s 2.98M/s 1.87M/s 3M/s 2.98M/s 2.99M/s 2.99M/s 2.99M/s 2.97M/s 2.99M/s 64KiB 2.98M/s 3M/s 2.98M/s 2.98M/s 2.99M/s 3M/s 2.19M/s 2.19M/s 2.18M/s 2.19M/s 2.19M/s 2.19M/s 2.2M/s 2.2M/s 2.19M/s 32KiB 2.82M/s 2.84M/s 2.84M/s 2.83M/s 2.83M/s 2.82M/s 2.83M/s 2.86M/s 2.83M/s 2.83M/s 2.85M/s 2.84M/s 2.84M/s 2.84M/s 2.84M/s 16KiB 5.14M/s 2.61M/s 2.6M/s 2.62M/s 2.61M/s 2.62M/s 2.62M/s 2.61M/s 2.61M/s 2.62M/s 2.61M/s 2.6M/s 2.6M/s 2.61M/s 2.63M/s 8KiB 2.24M/s 1.56M/s 2.26M/s 2.25M/s 2.25M/s 2.25M/s 2.23M/s 2.24M/s 2.25M/s 2.23M/s 2.24M/s 2.25M/s 1.34M/s 1.34M/s 1.34M/s 4KiB 1.04M/s 1.05M/s 1.05M/s 1.05M/s 1.05M/s 1.05M/s 919K/s 779K/s 783K/s 785K/s 787K/s 784K/s 784K/s 785K/s 783K/s 2KiB 507K/s 464K/s 507K/s 508K/s 507K/s 508K/s 466K/s 430K/s 429K/s 428K/s 427K/s 429K/s 429K/s 429K/s 429K/s ^C bash-4.1# ^C bash-4.1#
Strange....still a lot of variation going on. I'll leave the final analysis up to you...obviously :)
On Thursday 28 July 2011 14:46:34 Ajax Criterion wrote:
bash-4.1# flashbench --findfat --fat-nr=15 --erasesize=$[1* 1024*1024] --random --blocksize=512 /dev/sdc 1MiB 3.04M/s 7.38M/s 3.06M/s 3.06M/s 3.06M/s 3.07M/s 3.05M/s 7.47M/s 7.46M/s 7.45M/s 7.42M/s 7.39M/s 7.39M/s 7.35M/s 7.46M/s 512KiB 7.09M/s 7.24M/s 3.04M/s 3.05M/s 3.07M/s 3.04M/s 2.41M/s 2.43M/s 2.42M/s 2.44M/s 3.16M/s 3.18M/s 3.18M/s 3.16M/s 3.16M/s 256KiB 3.01M/s 4.28M/s 4.27M/s 4.28M/s 4.28M/s 3.01M/s 2.39M/s 2.4M/s 2.41M/s 2.42M/s 2.4M/s 2.4M/s 2.4M/s 2.42M/s 2.41M/s 128KiB 6.76M/s 2.98M/s 3M/s 2.99M/s 2.97M/s 2.97M/s 2.98M/s 1.87M/s 3M/s 2.98M/s 2.99M/s 2.99M/s 2.99M/s 2.97M/s 2.99M/s 64KiB 2.98M/s 3M/s 2.98M/s 2.98M/s 2.99M/s 3M/s 2.19M/s 2.19M/s 2.18M/s 2.19M/s 2.19M/s 2.19M/s 2.2M/s 2.2M/s 2.19M/s 32KiB 2.82M/s 2.84M/s 2.84M/s 2.83M/s 2.83M/s 2.82M/s 2.83M/s 2.86M/s 2.83M/s 2.83M/s 2.85M/s 2.84M/s 2.84M/s 2.84M/s 2.84M/s 16KiB 5.14M/s 2.61M/s 2.6M/s 2.62M/s 2.61M/s 2.62M/s 2.62M/s 2.61M/s 2.61M/s 2.62M/s 2.61M/s 2.6M/s 2.6M/s 2.61M/s 2.63M/s 8KiB 2.24M/s 1.56M/s 2.26M/s 2.25M/s 2.25M/s 2.25M/s 2.23M/s 2.24M/s 2.25M/s 2.23M/s 2.24M/s 2.25M/s 1.34M/s 1.34M/s 1.34M/s 4KiB 1.04M/s 1.05M/s 1.05M/s 1.05M/s 1.05M/s 1.05M/s 919K/s 779K/s 783K/s 785K/s 787K/s 784K/s 784K/s 785K/s 783K/s 2KiB 507K/s 464K/s 507K/s 508K/s 507K/s 508K/s 466K/s 430K/s 429K/s 428K/s 427K/s 429K/s 429K/s 429K/s 429K/s ^C bash-4.1# ^C bash-4.1#
Strange....still a lot of variation going on. I'll leave the final analysis up to you...obviously
I have no idea either. My guess is that it doesn't actually do anything special here, and all we see are side-effects of the way we measure.
Arnd
flashbench-results@lists.linaro.org
-
Ajax Criterion -
Arnd Bergmann