Re: [Flashbench] Lexar JumpDrive TwistTurn 4GB USB flashdrive

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