Salut, for housing a debian chroot in my android phone, I want to set up a 2.5G partition on this new micro sd card. For that, I want to figure out which parameters to give to mke2fs, as in
mkfs.ext4 -E stride=2,stripe-width=2048 -L debian_chroot /dev/sdb2
Now to figure out the internal erase block size, flashbench was recommended. But I can not quite make sense of my result..
# fdisk.distrib -l /dev/sdb
Disk /dev/sdb: 15.9 GB, 15931539456 bytes 255 heads, 63 sectors/track, 1936 cylinders, total 31116288 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: 0x000604f9
Device Boot Start End Blocks Id System /dev/sdb1 2048 25890815 12944384 b W95 FAT32 /dev/sdb2 25890816 31115263 2612224 83 Linux
# flashbench -va /dev/sdb --blocksize=1024 |(echo "align,pre [µs],on [µs],post [µs],diff [µs]" && sed -r 's/\w+ //g;s/\t/,/g;s/[0-9]+ns*/0/g;s/µs//g')|tee flashbench-16gb-sandisk-extreme-microsdhc-blocksize-1024.csv # flashbench -va /dev/sdb --blocksize=$[3*1024] |(echo "align,pre [µs],on [µs],post [µs],diff [µs]" && sed -r 's/\w+ //g;s/\t/,/g;s/[0-9]+ns*/0/g;s/µs//g')|tee flashbench-16gb-sandisk-extreme-microsdhc-blocksize-$[3*1024].csv
resulting CSV files attached.. I created a spreadsheet chart showing a drop.. does this mean the erasure block size is 128KB?
That would give a stripe-width of 128KB/(2*4KB)=16?
And I have not at all grokked the benefit/applicability of open-au/open-au-nr for practical purposes.. Any clarification greatly appreciated.
#Regards!Marcel
On 07/07/2014 06:31 AM, Marcel Partap wrote:
Salut, for housing a debian chroot in my android phone, I want to set up a 2.5G partition on this new micro sd card. For that, I want to figure out which parameters to give to mke2fs, as in
mkfs.ext4 -E stride=2,stripe-width=2048 -L debian_chroot /dev/sdb2
Finding the erase block size in order to align the partitions is more important than the mkfs parameters and will make a much larger impact on performance than setting ideal stride and stripe.
Now to figure out the internal erase block size, flashbench was recommended. But I can not quite make sense of my result..
# fdisk.distrib -l /dev/sdb
Disk /dev/sdb: 15.9 GB, 15931539456 bytes 255 heads, 63 sectors/track, 1936 cylinders, total 31116288 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: 0x000604f9
Device Boot Start End Blocks Id System /dev/sdb1 2048 25890815 12944384 b W95 FAT32 /dev/sdb2 25890816 31115263 2612224 83 Linux
andrew@boomboom:~$ factor 15931539456 15931539456: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 7 1447
So possibly a base 2 MiB erase block size, but also possibly masked by SanDisk's controller as in some other SanDisk cards.
# flashbench -va /dev/sdb --blocksize=1024 |(echo "align,pre [µs],on [µs],post [µs],diff [µs]" && sed -r 's/\w+ //g;s/\t/,/g;s/[0-9]+ns*/0/g;s/µs//g')|tee flashbench-16gb-sandisk-extreme-microsdhc-blocksize-1024.csv # flashbench -va /dev/sdb --blocksize=$[3*1024] |(echo "align,pre [µs],on [µs],post [µs],diff [µs]" && sed -r 's/\w+ //g;s/\t/,/g;s/[0-9]+ns*/0/g;s/µs//g')|tee flashbench-16gb-sandisk-extreme-microsdhc-blocksize-$[3*1024].csv
resulting CSV files attached.. I created a spreadsheet chart showing a drop.. does this mean the erasure block size is 128KB?
That would give a stripe-width of 128KB/(2*4KB)=16?
Likely the card does not have an erase block size smaller than 2 MiB due to the amount of flash in it, so 128 kiB is probably not the correct erase block size. Most larger sized cards have 2, 4 or 8 MiB erase blocks these days.
It's probably easier for those who read this list to see raw output of flashbench rather than looking at csv files or plots in order to assist with interpreting your results.
If you see a drop in the times when doing a read test, this often will indicate the size of the erase block, but not always. It's just a first pass test which is quick to run and does not damage contents of the card.
If you would prefer to pick a size to use which may not be the exact size of your erase blocks but should be a multiple, use 24 MiB to align your partitions. 24 is the least common multiple of 1.5, 2, 3, 4, 6, and 8 MiB (which are the most common erase block sizes in my experience) and on most disks will result in aligned partitions but does possibly throw away more space as unused than finding the exact erase block size.
And I have not at all grokked the benefit/applicability of open-au/open-au-nr for practical purposes.. Any clarification greatly appreciated.
The open-au tests will show you how many open erase blocks the card can handle. For example, if only one open-au is possible on a card, it may have to finish up doing the read-erase-write or read-write-erase garbage collection action before it will accept another write. This can slow writes of small sizes.
Arnd wrote up a good overview: http://lwn.net/Articles/428584/
Please see one of my flashbench results to give you some ideas on the commands to run and the meaning of the results. This is a Samsung card which is not very good: http://lists.linaro.org/pipermail/flashbench-results/2013-August/000452.html
Thanks, Andrew
Finding the erase block size in order to align the partitions is more important than the mkfs parameters and will make a much larger impact on performance than setting ideal stride and stripe.
[...]
Likely the card does not have an erase block size smaller than 2 MiB due to the amount of flash in it, so 128 kiB is probably not the correct erase block size. Most larger sized cards have 2, 4 or 8 MiB erase blocks these days.
Why then would there not be a step in timing difference at f.e. 2MiB?
It's probably easier for those who read this list to see raw output of flashbench rather than looking at csv files or plots in order to assist with interpreting your results.
Here it is.
flashbench --count=1000 -a /dev/sdb --blocksize=$((1*1024)) align 4294967296 pre 611µs on 799µs post 615µs diff 186µs align 2147483648 pre 615µs on 792µs post 619µs diff 175µs align 1073741824 pre 608µs on 812µs post 613µs diff 201µs align 536870912 pre 615µs on 771µs post 619µs diff 153µs align 268435456 pre 607µs on 774µs post 612µs diff 164µs align 134217728 pre 614µs on 800µs post 617µs diff 185µs align 67108864 pre 614µs on 799µs post 618µs diff 183µs align 33554432 pre 612µs on 783µs post 614µs diff 171µs align 16777216 pre 607µs on 748µs post 613µs diff 138µs align 8388608 pre 605µs on 742µs post 605µs diff 137µs align 4194304 pre 603µs on 749µs post 608µs diff 143µs align 2097152 pre 603µs on 750µs post 607µs diff 146µs align 1048576 pre 601µs on 741µs post 603µs diff 139µs align 524288 pre 603µs on 767µs post 615µs diff 158µs align 262144 pre 597µs on 747µs post 604µs diff 146µs align 131072 pre 606µs on 751µs post 611µs diff 143µs align 65536 pre 603µs on 705µs post 609µs diff 99.1µs align 32768 pre 606µs on 694µs post 595µs diff 93.6µs align 16384 pre 601µs on 703µs post 604µs diff 100µs align 8192 pre 614µs on 613µs post 611µs diff 351ns align 4096 pre 613µs on 616µs post 608µs diff 5.19µs align 2048 pre 612µs on 613µs post 614µs diff 276ns
What would you make from that? The drop-off definitely is @128K...
If you see a drop in the times when doing a read test, this often will indicate the size of the erase block, but not always. It's just a first pass test which is quick to run and does not damage contents of the card.
Why not always? And is it improbable that sandisk gave the card such small blocks for better small-file performance?
If you would prefer to pick a size to use which may not be the exact size of your erase blocks but should be a multiple, use 24 MiB to align your partitions. 24 is the least common multiple of 1.5, 2, 3, 4, 6, and 8 MiB (which are the most common erase block sizes in my experience) and on most disks will result in aligned partitions but does possibly throw away more space as unused than finding the exact erase block size.
That sounds like a good idea though, thanks.
#Regards/MPartap
On 08/06/2014 02:50 PM, Marcel Partap wrote:
Finding the erase block size in order to align the partitions is more important than the mkfs parameters and will make a much larger impact on performance than setting ideal stride and stripe.
[...]
Likely the card does not have an erase block size smaller than 2 MiB due to the amount of flash in it, so 128 kiB is probably not the correct erase block size. Most larger sized cards have 2, 4 or 8 MiB erase blocks these days.
Why then would there not be a step in timing difference at f.e. 2MiB?
SanDisk controllers are known to have fancy tricks which result in better performance under certain loads, hiding the actual erase block size may be a side effect. I don't really know the root cause but I have seen this kind of behavior before.
It's probably easier for those who read this list to see raw output of flashbench rather than looking at csv files or plots in order to assist with interpreting your results.
Here it is.
flashbench --count=1000 -a /dev/sdb --blocksize=$((1*1024)) align 4294967296 pre 611µs on 799µs post 615µs diff 186µs align 2147483648 pre 615µs on 792µs post 619µs diff 175µs align 1073741824 pre 608µs on 812µs post 613µs diff 201µs align 536870912 pre 615µs on 771µs post 619µs diff 153µs align 268435456 pre 607µs on 774µs post 612µs diff 164µs align 134217728 pre 614µs on 800µs post 617µs diff 185µs align 67108864 pre 614µs on 799µs post 618µs diff 183µs align 33554432 pre 612µs on 783µs post 614µs diff 171µs align 16777216 pre 607µs on 748µs post 613µs diff 138µs align 8388608 pre 605µs on 742µs post 605µs diff 137µs align 4194304 pre 603µs on 749µs post 608µs diff 143µs align 2097152 pre 603µs on 750µs post 607µs diff 146µs align 1048576 pre 601µs on 741µs post 603µs diff 139µs align 524288 pre 603µs on 767µs post 615µs diff 158µs align 262144 pre 597µs on 747µs post 604µs diff 146µs align 131072 pre 606µs on 751µs post 611µs diff 143µs align 65536 pre 603µs on 705µs post 609µs diff 99.1µs align 32768 pre 606µs on 694µs post 595µs diff 93.6µs align 16384 pre 601µs on 703µs post 604µs diff 100µs align 8192 pre 614µs on 613µs post 611µs diff 351ns align 4096 pre 613µs on 616µs post 608µs diff 5.19µs align 2048 pre 612µs on 613µs post 614µs diff 276ns
What would you make from that? The drop-off definitely is @128K...
Could be caching or intermediate SLC flash or the page size.
Try running with '--blocksize=$(3*1024)' and see if any noticeable changes happen. Some SanDisk cards look like 1.5 MiB erase blocks and this can be exposed with the 3072 blocksize.
Alternatively, you can do write testing and move the offset to span where you think the erase block edges are and see if performance drops off when crossing the erase block boundary. This is a better indicator but takes much longer to do.
Thanks, Andrew
On 11/08/14 13:44, Andrew Bradford wrote:
On 08/06/2014 02:50 PM, Marcel Partap wrote:
Finding the erase block size in order to align the partitions is more important than the mkfs parameters and will make a much larger impact on performance than setting ideal stride and stripe.
[...]
Likely the card does not have an erase block size smaller than 2 MiB due to the amount of flash in it, so 128 kiB is probably not the correct erase block size. Most larger sized cards have 2, 4 or 8 MiB erase blocks these days.
Why then would there not be a step in timing difference at f.e. 2MiB?
SanDisk controllers are known to have fancy tricks which result in better performance under certain loads, hiding the actual erase block size may be a side effect. I don't really know the root cause but I have seen this kind of behavior before.
It's probably easier for those who read this list to see raw output of flashbench rather than looking at csv files or plots in order to assist with interpreting your results.
Here it is.
flashbench --count=1000 -a /dev/sdb --blocksize=$((1*1024)) align 4294967296 pre 611µs on 799µs post 615µs diff 186µs align 2147483648 pre 615µs on 792µs post 619µs diff 175µs align 1073741824 pre 608µs on 812µs post 613µs diff 201µs align 536870912 pre 615µs on 771µs post 619µs diff 153µs align 268435456 pre 607µs on 774µs post 612µs diff 164µs align 134217728 pre 614µs on 800µs post 617µs diff 185µs align 67108864 pre 614µs on 799µs post 618µs diff 183µs align 33554432 pre 612µs on 783µs post 614µs diff 171µs align 16777216 pre 607µs on 748µs post 613µs diff 138µs align 8388608 pre 605µs on 742µs post 605µs diff 137µs align 4194304 pre 603µs on 749µs post 608µs diff 143µs align 2097152 pre 603µs on 750µs post 607µs diff 146µs align 1048576 pre 601µs on 741µs post 603µs diff 139µs align 524288 pre 603µs on 767µs post 615µs diff 158µs align 262144 pre 597µs on 747µs post 604µs diff 146µs align 131072 pre 606µs on 751µs post 611µs diff 143µs align 65536 pre 603µs on 705µs post 609µs diff 99.1µs align 32768 pre 606µs on 694µs post 595µs diff 93.6µs align 16384 pre 601µs on 703µs post 604µs diff 100µs align 8192 pre 614µs on 613µs post 611µs diff 351ns align 4096 pre 613µs on 616µs post 608µs diff 5.19µs align 2048 pre 612µs on 613µs post 614µs diff 276ns
What would you make from that? The drop-off definitely is @128K...
Could be caching or intermediate SLC flash or the page size.
Try running with '--blocksize=$(3*1024)' and see if any noticeable changes happen. Some SanDisk cards look like 1.5 MiB erase blocks and this can be exposed with the 3072 blocksize.
align 3221225472 pre 714µs on 829µs post 710µs diff 117µs align 1610612736 pre 712µs on 834µs post 717µs diff 120µs align 805306368 pre 713µs on 823µs post 703µs diff 115µs align 402653184 pre 728µs on 839µs post 724µs diff 113µs align 201326592 pre 722µs on 846µs post 728µs diff 120µs align 100663296 pre 721µs on 838µs post 721µs diff 118µs align 50331648 pre 723µs on 845µs post 729µs diff 119µs align 25165824 pre 711µs on 843µs post 731µs diff 122µs align 12582912 pre 716µs on 828µs post 727µs diff 107µs align 6291456 pre 717µs on 841µs post 732µs diff 117µs align 3145728 pre 720µs on 839µs post 721µs diff 118µs align 1572864 pre 717µs on 840µs post 721µs diff 121µs align 786432 pre 726µs on 849µs post 703µs diff 134µs align 393216 pre 720µs on 845µs post 724µs diff 122µs align 196608 pre 729µs on 742µs post 721µs diff 16.7µs align 98304 pre 724µs on 739µs post 729µs diff 12.8µs align 49152 pre 722µs on 715µs post 725µs diff -8583ns align 24576 pre 711µs on 713µs post 713µs diff 977ns align 12288 pre 733µs on 726µs post 737µs diff -9350ns align 6144 pre 725µs on 730µs post 739µs diff -1197ns
Alternatively, you can do write testing and move the offset to span where you think the erase block edges are and see if performance drops off when crossing the erase block boundary. This is a better indicator but takes much longer to do.
I did something in that line, which indeed took a long time to do... I created a FAT32 partition at sector 63 (unaligned), 1MiB, 2MiB, 3MiB and 24MiB and ran # iozone -a -i 0 -i 1 -i 2 -g 32m -I # -a: automatic mode # -i 0 -i 1 -i 2: test 0=write/rewrite, 1=read/re-read, 2=random-read/write # -g 32m: maximum file size 32MB # -I: DIRECT IO (bypass cache) on each, than fed them into the "iozone-results-comparator" .. resulting graphs is attached and leaves me inconclusive. Huh?
#Regards!MPartap
flashbench-results@lists.linaro.org
-
Andrew Bradford -
Marcel Partap