On Friday 25 March 2011 02:07:46 Michael Monnerie wrote:
On Donnerstag, 24. März 2011 Arnd Bergmann wrote:
On Thursday 24 March 2011, Michael Monnerie wrote: Be careful here. The original FAT layout is typically made specifically for this stick, so it's probably a good idea to make a backup of the first few blocks.
Too late. It's NTFS since a long time, I converted it as FAT32 only stores files of 2GB, which is too small for my files. I use this stick to copy DVDs on it, then stick it in the TV and look from there. No DVD player available.
Ok, I see. In that case, I'd recommend creating a new partition table with the first partition aligned to the erase block size.
I've committed some updates now that might help make the --open-au results a bit clearer, and faster.
What I would recommend now is to update to the latest git version (just uploaded), and then try increasing numbers of --open-au-nr= with 4 MB erasesize, until you hit the cutoff. Try the same with --random, for the last fast one and the first slow one:
OK I did, but with your new version I get seriously different results than before: # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=5 sched_setscheduler: Operation not permitted 4MiB 7.66M/s 2MiB 3.42M/s 1MiB 8.15M/s 512KiB 7.99M/s 256KiB 381K/s 128KiB 189K/s 64KiB 7.6M/s 32KiB 6.75M/s 16KiB 46.8K/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=4 sched_setscheduler: Operation not permitted 4MiB 7.6M/s 2MiB 6.75M/s 1MiB 6.32M/s 512KiB 8.42M/s 256KiB 5.97M/s 128KiB 4.17M/s 64KiB 6.07M/s 32KiB 7.13M/s 16KiB 4.67M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=3 sched_setscheduler: Operation not permitted 4MiB 8.94M/s 2MiB 6.95M/s 1MiB 7.02M/s 512KiB 6.91M/s 256KiB 6.82M/s 128KiB 5.37M/s 64KiB 6.96M/s 32KiB 5.92M/s 16KiB 4.4M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=2 sched_setscheduler: Operation not permitted 4MiB 10.5M/s 2MiB 6.91M/s 1MiB 7.03M/s 512KiB 6.92M/s 256KiB 6.75M/s 128KiB 5.02M/s 64KiB 6.91M/s 32KiB 6.01M/s 16KiB 4.68M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=1 sched_setscheduler: Operation not permitted 4MiB 23.5M/s 2MiB 6.73M/s 1MiB 7.05M/s 512KiB 6.93M/s 256KiB 6.73M/s 128KiB 4.19M/s 64KiB 6.71M/s 32KiB 6.08M/s 16KiB 4.6M/s
=> N is the number of 4 MB blocks that can not be handled
So I guess 5 would be my number now?
Exactly.
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=(N-1) --random ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au -nr=N --random => Verify that the (N-1) --random case is still fast
OK, looks good: # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=4 --random sched_setscheduler: Operation not permitted 4MiB 8.28M/s 2MiB 6.98M/s 1MiB 7.04M/s 512KiB 6.99M/s 256KiB 6.82M/s 128KiB 5.59M/s 64KiB 7.01M/s 32KiB 4.42M/s 16KiB 4.69M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=5 --random sched_setscheduler: Operation not permitted 4MiB 7.17M/s 2MiB 5.17M/s 1MiB 6.77M/s 512KiB 3.66M/s 256KiB 746K/s 128KiB 373K/s 64KiB 647K/s 32KiB 328K/s 16KiB 93.3K/s
Ok, so random access is just as fast as linear access. Good!
./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=((N-1)/2) --random ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=(N-1) --random ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=(N-1) --random
I guess the last should have been open-au-nr=(N)? Anyway, I didn't run the last test, as already the second shows drastic reduction:
# ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=2 --random sched_setscheduler: Operation not permitted 8MiB 14.4M/s 4MiB 7.56M/s 2MiB 6.7M/s 1MiB 6.97M/s 512KiB 6.86M/s 256KiB 6.67M/s 128KiB 4.53M/s 64KiB 6.61M/s 32KiB 5.8M/s 16KiB 4.62M/s # ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=4 --random sched_setscheduler: Operation not permitted 8MiB 11.2M/s 4MiB 9.27M/s 2MiB 3.42M/s 1MiB 5.18M/s 512KiB 2.76M/s 256KiB 747K/s 128KiB 373K/s 64KiB 344K/s (cancelled here, confirmed it's slow)
So would it be right to guess it's an 8M erasesize with 2 au?
Actually, it confirms that the erase size is 4 MB. We've already established that it can have 4 but not 5 erase blocks open.
The last test showed that when flashbench tries to write to 2*8MB, it's fast, which was expected because that can be done using four 4MB erase blocks. If an erase block was 8 MB, you would also be able to write four of them efficiently.
If so, what should an ideal partition table look like?
# create the partititon table echo 8192,,7 | sudo sfdisk -uS -L -f /dev/sde
# show the new table sudo fdisk /dev/sdd -l -u
====>
Device Boot Start End Blocks Id System /dev/sdd1 8192 XXXXXX XXXXXX 7 NTFS/HPFS Warning: Partition 1 does not end on cylinder boundary.
<===
Before you do that, could I ask you to run
flashbench --findfat --fat-nr=6 /dev/sde --blocksize=512
and post the results here?
That will add the two missing pieces of information for the survey, the page size and the location of the FAT. I've already entered the other data into the wiki.
Is NTFS tuneable for this stick? I've used a block size of 64k to keep performance up. Too bad my TV doesn't understand XFS or similar FS.
I don't know anything about NTFS, sorry.
Arnd