Name | Last modified | Size | Description | |
---|---|---|---|---|
Parent Directory | - | |||
README.html | 2012-06-25 04:55 | 6.8K | flashbench for the Pandora | |
flashbench | 2012-06-17 23:00 | 31K | ||
README | 2012-06-17 23:00 | 5.0K | ||
This is a small utility program that helps guess the erase block size of you flash media. It was downloaded from git://git.linaro.org/people/arnd/flashbench.git and compiled for the Pandora. If you are interested in the how and why read the README.
Blocks on flash media can only be erased in larger blocks. If the partitions on your flash medium are not align to these erase block boundaries writing a single block can result in two writes instead of one, crippeling you I/O-performance.
GParted and other newer formating utilities already align the partitions to 1MB. But these utilities are made for harddisks. As modern harddisk have a physical block size of 4096 Bytes they have the same kind of problem, but the erase block boundary of flash cards can be much larger. My 64GB card for example has an erase block size of 8MB.
This is the output of a bonnie++ run on the Pandora with an ext4 partition starting at block 1:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
yoda 1G 12317 33 5553 21 16483 31 72.2 27
Latency 733ms 664ms 150ms 6901ms
Version 1.96 ------Sequential Create------ --------Random Create--------
yoda -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 69 6 26797 70 46 3 69 5 +++++ +++ 44 3
Latency 1107ms 32257us 2508ms 1025ms 15868us 2453ms
Same card, same pandora, but on an aligned partition:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
yoda 1G 13084 29 5749 22 15897 33 74.0 21
Latency 4949ms 505ms 32286us 3246ms
Version 1.96 ------Sequential Create------ --------Random Create--------
yoda -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 4380 59 +++++ +++ 5384 49 4220 55 +++++ +++ 5215 49
Latency 9032us 16541us 6958us 1250us 1128us 2197us
I/O with larger blocks stayed about the same (small variations are to be expected between test runs). But file creation and deletion (operations that require updates to small blocks) are boosted nearly by a factor of 100.
$ cd /tmp
$ wget http://lxtek.de/pandora/flashbench/flashbench
$ chmod a+x flashbench
$ sudo ./flashbench -a /dev/mmcblk0 --blocksize=1024
This should give you output like the following:
align 17179869184 pre 593µs on 981µs post 833µs diff 268µs
align 8589934592 pre 580µs on 1.01ms post 824µs diff 305µs
align 4294967296 pre 750µs on 1.2ms post 1.02ms diff 314µs
align 2147483648 pre 780µs on 1.2ms post 1.01ms diff 303µs
align 1073741824 pre 1.16ms on 1.49ms post 1.39ms diff 214µs
align 536870912 pre 1.14ms on 1.52ms post 1.39ms diff 253µs
align 268435456 pre 1.15ms on 1.52ms post 1.41ms diff 242µs
align 134217728 pre 1.15ms on 1.52ms post 1.37ms diff 262µs
align 67108864 pre 1.12ms on 1.49ms post 1.39ms diff 231µs
align 33554432 pre 1.16ms on 1.53ms post 1.4ms diff 255µs
align 16777216 pre 1.15ms on 1.55ms post 1.4ms diff 275µs
align 8388608 pre 1.15ms on 1.53ms post 1.39ms diff 264µs
align 4194304 pre 1.13ms on 1.4ms post 1.38ms diff 140µs
align 2097152 pre 1.11ms on 1.43ms post 1.37ms diff 190µs
align 1048576 pre 1.12ms on 1.42ms post 1.4ms diff 163µs
align 524288 pre 1.14ms on 1.44ms post 1.38ms diff 183µs
align 262144 pre 1.12ms on 1.43ms post 1.39ms diff 177µs
align 131072 pre 1.12ms on 1.42ms post 1.39ms diff 166µs
align 65536 pre 1.13ms on 1.42ms post 1.36ms diff 172µs
align 32768 pre 1.13ms on 1.43ms post 1.38ms diff 170µs
align 16384 pre 1.12ms on 1.44ms post 1.39ms diff 190µs
align 8192 pre 1.12ms on 1.43ms post 1.39ms diff 172µs
align 4096 pre 1.26ms on 1.26ms post 1.23ms diff 15.3µs
align 2048 pre 1.34ms on 1.32ms post 1.27ms diff 13.1µs
The interesting part is the diff column (details are in the README). Between 4194304 and 8388608 it makes a jump. So the erase block boundary for this particular card is probably 8388608 Bytes. So you should align your partitions to 8MB or to 16384 blocks (8388608 Byte / 512 Byte (the block size)).
The easiest way to partition your card is probably with GParted. "fdisk" on the Pandora is NOT a good idea as it is too old and cannot disable the DOS compatibility mode. You can do some magic with the -S (sectors) and -H (heads) geometry settings, but it is much easier to partition the disk with GParted or a a recent (>= 2.17.1) version of fdisk. I guess this should also be possible under Windows, but I don't know how. So if in doubt pop in that Knoppix, grml or Ubuntu LiveCD.
In GParted select "MiB" alignment and just work with values that are multiples of your erase block size. So leave 8MB (or your erase block size) free in front of your first partition. GParted should do the finetuning.
You can check if you did everything right with the fdisk utility on your Pandora:
$ sudo fdisk -lu /dev/mmcblk1
Disk /dev/mmcblk1: 66.4 GB, 66436726784 bytes
4 heads, 16 sectors/track, 2027488 cylinders, total 129759232 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/mmcblk1p1 16384 127664127 63823872 83 Linux
/dev/mmcblk1p2 127664128 129759231 1047552 82 Linux swap / Solaris
If the start block is divisible by your erase block size everything is fine. In the example everything looks good: 16384 / 16384 = 1.0 (duuuh!) and 127664128 / 16384 = 7792.0.
Now you can start your favorite chroot (like schroot :-)) and start a bonnie++ test run to see how much your I/O performance for small blocks has improved and feel good about it.