flashbench on windows
windows上的flashbench对u盘读写速度的测试非常简单，他把100M文件写入到盘中，这样就能测试写入速度，然后读取这个文件，从而获取读取速度。
这个软件使用起来也很简单，在界面的”Drive”后面选择u盘对应的盘符，然后点击Benchmark，就开始测试了，测试的结果会在软件的下半部分通过折线图显示出来。
在FlashBench界面的底部，你会看到16MB,8MB,4MB等字。这个代表每次测试时写入的单个文件的大小。由于flash介质在响应时间上会有差异，所以写入多个文件之间是会有间隔的，所以同样是100MB，1KB文件的数量会比16MB文件的多很多，那么传输小文件时实际的读写性能会下降的厉害。
flashbench on linux
下载git clone git:///people/arnd/flashbench.git
另外一些关于这个软件的参数及使用的讨论/mailman/listinfo/flashbench-results
align
align测试用于发现erase block size和page size大小。
因为sd卡所用的flash颗粒是有wear leveling的，而现有的操作系统对于如何格式化和访问flash还没有成熟的方案，所以系统默认的格式化方案对于flash的访问速度和life time来说并不是最优的方案，选择一个最佳的erase block size 和page size可以提高sd卡的读写性能和延长使用寿命。
This is just a non-destructive read test. Sometimes read performance when spanning two eraseblocks will be slower than when reading only in one erase block. The “pre” reads just prior to an expected eraseblock boundary, the “on” reads spanning an eraseblock boundary, and the “post” reads just after an eraseblock boundary. Any spot where the “diff” times drop dramatically may indicate the likely eraseblock size or the likely write page size (write page size will always be smaller than an eraseblock).
上面这段话是从别的地方摘过来的，个人理解align测试的主要原理是跨erase block size读取n个字节的时间与在同一个erase block size读取n个字节的时间是不一样的。测试page size的原理也是一样的。
~ # flashbench -a -b 1024 /dev/mmcblk0 align 2147483648 pre 678us on 910us post 682usdiff 230usalign 1073741824 pre 778us on 1.08ms post 754usdiff 314usalign 536870912 pre 764us on 1.02ms post 736usdiff 271usalign 268435456 pre 744us on 994us post 762usdiff 242usalign 134217728 pre 774us on 1.05ms post 688usdiff 314usalign 67108864 pre 738us on 984us post 725usdiff 253usalign 33554432 pre 756us on 1.03ms post 740usdiff 279usalign 16777216 pre 739us on 1.02ms post 725usdiff 292usalign 8388608 pre 704us on 950us post 694usdiff 251usalign 4194304 pre 694us on 937us post 689usdiff 246usalign 2097152 pre 698us on 825us post 697usdiff 127usalign 1048576 pre 694us on 783us post 701usdiff 85usalign 524288 pre 695us on 785us post 706usdiff 84.7usalign 262144 pre 696us on 784us post 706usdiff 83.4usalign 131072 pre 691us on 780us post 705usdiff 82.5usalign 65536pre 691us on 781us post 704usdiff 82.9usalign 32768pre 697us on 786us post 710usdiff 82.3usalign 16384pre 702us on 779us post 691usdiff 82.4usalign 8192pre 696us on 735us post 698usdiff 37.7usalign 4096pre 699us on 735us post 698usdiff 36.5usalign 2048pre 700us on 734us post 696usdiff 35.5us
通过这个命令可以看出erase size可能为4194304和page size为16384
使用上面这个命令尝试使用不同的-b参数(1024, 2048, 4096…)来找出分布位置比较稳定的erase block size和page size，找出一个稳定的分布参考这篇文章beaglebone black简单入门（三），这个实验中发现了4k * 3 * N作为page是较为规律的，且突变都发生在12M，最后测试在这种情况下读写速度，发现使用24k作为page size，12M作为erase block size是比较好的。我这里在自己的板子上做了实验数据如下，可以看出erase block size比较稳定的分布在4194304，而page size分布在16384。
~ # flashbench -a -b 1024 /dev/mmcblk0 align 2147483648 pre 672us on 905us post 668usdiff 235usalign 1073741824 pre 779us on 1.07ms post 751usdiff 308usalign 536870912 pre 767us on 1.02ms post 728usdiff 269usalign 268435456 pre 740us on 997us post 766usdiff 244usalign 134217728 pre 772us on 1.04ms post 683usdiff 315usalign 67108864 pre 730us on 982us post 721usdiff 256usalign 33554432 pre 744us on 1.02ms post 730usdiff 286usalign 16777216 pre 740us on 1.03ms post 728usdiff 293usalign 8388608 pre 694us on 943us post 693usdiff 249usalign 4194304 pre 692us on 936us post 683usdiff 249usalign 2097152 pre 696us on 817us post 693usdiff 123usalign 1048576 pre 693us on 781us post 703usdiff 83.5usalign 524288 pre 693us on 788us post 707usdiff 87.9usalign 262144 pre 693us on 780us post 704usdiff 81.9usalign 131072 pre 691us on 779us post 705usdiff 81.3usalign 65536pre 694us on 779us post 701usdiff 81.7usalign 32768pre 693us on 785us post 701usdiff 87.6usalign 16384pre 701us on 774us post 691usdiff 78usalign 8192pre 695us on 734us post 699usdiff 36.7usalign 4096pre 699us on 733us post 699usdiff 34.3usalign 2048pre 698us on 732us post 697usdiff 35.1us~ # ~ # flashbench -a -b 2048 /dev/mmcblk0 align 2147483648 pre 705us on 921us post 701usdiff 219usalign 1073741824 pre 792us on 1.08ms post 776usdiff 301usalign 536870912 pre 789us on 1.03ms post 752usdiff 262usalign 268435456 pre 761us on 1.01ms post 785usdiff 234usalign 134217728 pre 798us on 1.06ms post 708usdiff 303usalign 67108864 pre 756us on 997us post 747usdiff 246usalign 33554432 pre 759us on 1.04ms post 751usdiff 282usalign 16777216 pre 758us on 1.03ms post 744usdiff 282usalign 8388608 pre 722us on 962us post 716usdiff 242usalign 4194304 pre 714us on 956us post 712usdiff 243usalign 2097152 pre 723us on 835us post 719usdiff 114usalign 1048576 pre 719us on 794us post 727usdiff 70.6usalign 524288 pre 721us on 803us post 730usdiff 77usalign 262144 pre 719us on 795us post 728usdiff 71.3usalign 131072 pre 717us on 790us post 728usdiff 67.6usalign 65536pre 720us on 797us post 729usdiff 72.7usalign 32768pre 718us on 799us post 727usdiff 76.4usalign 16384pre 727us on 790us post 716usdiff 68.4usalign 8192pre 722us on 749us post 724usdiff 26usalign 4096pre 720us on 745us post 719usdiff 25.7us~ # ~ # flashbench -a -b 4096 /dev/mmcblk0 align 2147483648 pre 756us on 943us post 756usdiff 187usalign 1073741824 pre 846us on 1.11ms post 828usdiff 276usalign 536870912 pre 848us on 1.05ms post 802usdiff 228usalign 268435456 pre 803us on 1.03ms post 840usdiff 209usalign 134217728 pre 843us on 1.08ms post 759usdiff 280usalign 67108864 pre 806us on 1.02ms post 797usdiff 220usalign 33554432 pre 805us on 1.06ms post 810usdiff 253usalign 16777216 pre 813us on 1.05ms post 800usdiff 246usalign 8388608 pre 764us on 991us post 771usdiff 224usalign 4194304 pre 773us on 985us post 763usdiff 217usalign 2097152 pre 762us on 857us post 768usdiff 91.9usalign 1048576 pre 783us on 827us post 781usdiff 44.6usalign 524288 pre 766us on 824us post 787usdiff 47.6usalign 262144 pre 775us on 819us post 783usdiff 40.1usalign 131072 pre 769us on 813us post 784usdiff 37.1usalign 65536pre 774us on 822us post 781usdiff 44.5usalign 32768pre 771us on 825us post 781usdiff 48.6usalign 16384pre 778us on 816us post 779usdiff 37.5usalign 8192pre 773us on 770us post 773usdiff -2926ns~ # ~ # flashbench -a -b 8192 /dev/mmcblk0 align 2147483648 pre 861us on 1.06ms post 859usdiff 195usalign 1073741824 pre 956us on 1.22ms post 937usdiff 272usalign 536870912 pre 952us on 1.17ms post 911usdiff 235usalign 268435456 pre 905us on 1.13ms post 944usdiff 203usalign 134217728 pre 948us on 1.19ms post 870usdiff 279usalign 67108864 pre 912us on 1.12ms post 924usdiff 202usalign 33554432 pre 920us on 1.16ms post 917usdiff 244usalign 16777216 pre 908us on 1.16ms post 921usdiff 242usalign 8388608 pre 870us on 1.09ms post 878usdiff 216usalign 4194304 pre 872us on 1.08ms post 871usdiff 209usalign 2097152 pre 874us on 951us post 874usdiff 76.9usalign 1048576 pre 879us on 927us post 884usdiff 45.6usalign 524288 pre 873us on 929us post 896usdiff 44.7usalign 262144 pre 887us on 931us post 895usdiff 39.8usalign 131072 pre 882us on 925us post 887usdiff 40usalign 65536pre 881us on 936us post 883usdiff 54.5usalign 32768pre 884us on 932us post 884usdiff 48usalign 16384pre 887us on 926us post 879usdiff 43.2us~ # ~ # flashbench -a -b 16384 /dev/mmcblk0 align 2147483648 pre 1.05mson 1.24ms post 1.09msdiff 165usalign 1073741824 pre 1.15mson 1.42ms post 1.13msdiff 279usalign 536870912 pre 1.15mson 1.37ms post 1.11msdiff 235usalign 268435456 pre 1.1ms on 1.32ms post 1.15msdiff 196usalign 134217728 pre 1.15mson 1.39ms post 1.08msdiff 277usalign 67108864 pre 1.11mson 1.33ms post 1.11msdiff 212usalign 33554432 pre 1.1ms on 1.36ms post 1.12msdiff 254usalign 16777216 pre 1.1ms on 1.36ms post 1.12msdiff 250usalign 8388608 pre 1.07mson 1.28ms post 1.09msdiff 201usalign 4194304 pre 1.08mson 1.27ms post 1.07msdiff 197usalign 2097152 pre 1.08mson 1.15ms post 1.08msdiff 72.7usalign 1048576 pre 1.1ms on 1.14ms post 1.09msdiff 47.1usalign 524288 pre 1.08mson 1.13ms post 1.1msdiff 40.7usalign 262144 pre 1.09mson 1.14ms post 1.1msdiff 43.2usalign 131072 pre 1.09mson 1.14ms post 1.1msdiff 44.4usalign 65536pre 1.09mson 1.13ms post 1.09msdiff 44.3usalign 32768pre 1.09mson 1.14ms post 1.09msdiff 50us~ # ~ # flashbench -a -b 32768 /dev/mmcblk0 align 2147483648 pre 1.56mson 1.64ms post 1.59msdiff 62.1usalign 1073741824 pre 1.65mson 1.82ms post 1.58msdiff 205usalign 536870912 pre 1.65mson 1.77ms post 1.57msdiff 163usalign 268435456 pre 1.59mson 1.71ms post 1.6msdiff 110usalign 134217728 pre 1.64mson 1.79ms post 1.55msdiff 193usalign 67108864 pre 1.6ms on 1.72ms post 1.58msdiff 131usalign 33554432 pre 1.59mson 1.74ms post 1.58msdiff 154usalign 16777216 pre 1.6ms on 1.76ms post 1.58msdiff 176usalign 8388608 pre 1.54mson 1.67ms post 1.54msdiff 124usalign 4194304 pre 1.54mson 1.67ms post 1.53msdiff 133usalign 2097152 pre 1.54mson 1.56ms post 1.52msdiff 26.9usalign 1048576 pre 1.57mson 1.56ms post 1.55msdiff 6.15usalign 524288 pre 1.55mson 1.56ms post 1.57msdiff 4.59usalign 262144 pre 1.55mson 1.57ms post 1.56msdiff 13.4usalign 131072 pre 1.55mson 1.56ms post 1.57msdiff 5.72usalign 65536pre 1.54mson 1.56ms post 1.55msdiff 11.7us~ #
open-au
用于寻找allocation unit(au)的数目，open-au代表copy-on-write-then-erase能同时发生的个数，越多代表读写性能越好
what is copy-and-write-then-erase ?
if you want to change just one bit within an eraseblock the controller will often copy the entire eraseblock contents to another eraseblock but with your one bit change. The controller will then set the old eraseblock to be erased, possibly in the background.
flashbench软件会测试从-b到-e之间指定的文件块大小写到sd卡里面，然后测试不同的速度，通过–open-au-nr选项可以指定open allocation unit的个数，根据不同open allocation unit个数的测试情况，可以看出sd卡拥有多少个open allocation unit。
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=1 /dev/mmcblk0 4MiB 10.1M/s 2MiB 6.16M/s 1MiB 7.86M/s 512KiB 16.7M/s 256KiB 16M/s 128KiB 14.8M/s 64KiB 13M/s 32KiB 10.9M/s 16KiB 8.87M/s ~ # ~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=2 /dev/mmcblk0 4MiB 10.9M/s 2MiB 16.8M/s 1MiB 16.6M/s 512KiB 16.6M/s 256KiB 15.8M/s 128KiB 14.7M/s 64KiB 12.8M/s 32KiB 10.8M/s 16KiB 8.53M/s ~ # ~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=8 /dev/mmcblk0 4MiB 14.2M/s 2MiB 16.8M/s 1MiB 13.8M/s 512KiB 16.6M/s 256KiB 15.9M/s 128KiB 14.7M/s 64KiB 12.7M/s 32KiB 10.7M/s 16KiB 8.45M/s ~ # ~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=9 /dev/mmcblk0 4MiB 16.7M/s 2MiB 7.2M/s 1MiB 3.22M/s 512KiB 1.44M/s 256KiB 692K/s 128KiB 344K/s 64KiB 170K/s 32KiB 84.9K/s 16KiB 42.5K/s
从上面看出来是在–open-au-nr=9时候的速度和前面比明显变慢了。所以–open-au-nr=8了。
为了更符合实际的情况，常常在测试的时候加上参数-r，表示随机写。
~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=1 -r /dev/mmcblk0 4MiB 18.4M/s 2MiB 3.61M/s 1MiB 3.13M/s 512KiB 3.13M/s 256KiB 1.12M/s 128KiB 576K/s 64KiB 324K/s 32KiB 157K/s 16KiB 75.3K/s ~ # ~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=2 -r /dev/mmcblk0 4MiB 5.12M/s 2MiB 16.6M/s 1MiB 12M/s 512KiB 4.51M/s 256KiB 1.12M/s 128KiB 591K/s 64KiB 323K/s 32KiB 156K/s 16KiB 74.8K/s ~ # ~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=8 -r /dev/mmcblk0 4MiB 16.8M/s 2MiB 13.8M/s 1MiB 12M/s 512KiB 4.29M/s 256KiB 1.09M/s 128KiB 592K/s 64KiB 322K/s 32KiB 156K/s 16KiB 74.6K/s ~ # ~ # flashbench -e 4194304 -b 16384 --open-au --open-au-nr=9 -r /dev/mmcblk0 4MiB 14.4M/s 2MiB 5.26M/s 1MiB 3.21M/s 512KiB 1.44M/s 256KiB 692K/s 128KiB 344K/s 64KiB 170K/s 32KiB 84.9K/s 16KiB 42.4K/s
fat
we can check if the first few eraseblocks have any special ability. Some cards will provide for the first few eraseblocks to be backed by SLC flash instead of MLC, or otherwise improve the performance of these special eraseblocks. This is important when using the card with the FAT filesystem as all the metadata is stored in the beginning of the disk and will get the most wear and small writes.
~ # flashbench /dev/mmcblk0 -f -e 41943044MiB 16.7M/s 32.2M/s 16.7M/s 16.8M/s 16.7M/s 16.7M/s 2MiB 16.8M/s 29.7M/s 16.6M/s 16.8M/s 16.8M/s 16.8M/s 1MiB 16.8M/s 29.9M/s 16.7M/s 16.8M/s 16.8M/s 16.7M/s 512KiB 16.6M/s 29.7M/s 16.5M/s 16.8M/s 16.7M/s 16.7M/s 256KiB 16.1M/s 25.8M/s 16M/s 16.1M/s 16M/s 16.1M/s 128KiB 14.7M/s 20M/s 14.6M/s 14.9M/s 14.8M/s 14.9M/s 64KiB 13M/s 20.5M/s 12.9M/s 13M/s 13M/s 12.9M/s 32KiB 11M/s 15.2M/s 10.8M/s 11M/s 10.9M/s 10.9M/s 16KiB 8.89M/s 9.97M/s 8.92M/s 8.95M/s 8.97M/s 8.96M/s
从上面可以看出来在第二列的速度明显比周围的速度快很多，可以作为fat分区会提高读写效率。
scatter
flashbench --scatter --scatter-order=N --scatter-span=N -b blocksize /dev/mmcblk0 -o /tmp/scatter_result
it is mainly a way to detect the block size if the -a test gives no conclusive result
–scatter
–scatter-order=M 定义scatter测试读取的区域，那么读取的区域的总大小为blocksize * 2^M (-b指定blocksize大小)
–scatter-span=N 一次读取的block的数量，那么一次读取的大小为blocksize * 2^N
-b 指定blocksize大小
-o 指定测试结果的输出文件
然后使用工具gnuplot将scatter_result绘制成二维图像，gnuplot -p -e ‘plot “scatter_result”’。
下面是我在自己这边的平台上测试的数据：
flashbench --scatter --scatter-order=11 --scatter-span=1 -b 16384 /dev/mmcblk0 -o /tmp/scatter_result
flashbench --scatter --scatter-order=11 --scatter-span=2 -b 16384 /dev/mmcblk0 -o /tmp/scatter_result
横轴为32M，因为这里的–scatter-order=11，所以整个scatter测试覆盖的区域是16384 * 2^11=32M，是sd卡最开头的32M
纵轴代表一次读取–scatter-span指定这么多个blocksize所要的时间，单位是ms
图中的每一个”+”都是一个测试结果，每次测试往后偏移blocksize大小，然后测试读取–scatter-span指定个数的blocksize大小的文件的时间，就得到一个”+”，横坐标代表偏移的位置，纵坐标代表读取–scatter-span指定个数的blocksize大小的文件的时间。
interval
用于分析从读取512 bytes到读取512 * 2^(N-1) bytes之间的速度与大小的关系，并将这些值做线性回归分析。
–interval-order=N 指定依次测试从512 bytes到512 * 2^N-1 bytes大小的blocksize
-c 指定测试的次数，这样每次测试的时候依次往后偏移9 * blocksize大小，指定次数测试完后会计算平均值，最大值，最小值等。
~ # flashbench -i --interval-order=13 -b 16384 /dev/mmcblk0 512 bytes: min 408us avg 493us max 924us: 1.25414 MB/s1024 bytes: min 439us avg 462us max 508us: 2.33469 MB/s2048 bytes: min 466us avg 488us max 510us: 4.39144 MB/s4096 bytes: min 535us avg 550us max 571us: 7.66278 MB/s8192 bytes: min 633us avg 687us max 744us: 12.9385 MB/s16384 bytes: min 906us avg 941us max 1.02ms: 18.0824 MB/s32768 bytes: min 1.34ms avg 1.43ms max 1.54ms: 24.4092 MB/s65536 bytes: min 2.2ms avg 2.27ms max 2.51ms: 29.8218 MB/s131072 bytes: min 3.34ms avg 3.7ms max 4.32ms: 39.1904 MB/s262144 bytes: min 6.22ms avg 7.17ms max 8.06ms: 42.1701 MB/s524288 bytes: min 11.8ms avg 15ms max 21.4ms: 44.5035 MB/s1048576 bytes: min 27.7ms avg 30.5ms max 43.6ms: 37.871 MB/s2097152 bytes: min 55ms avg 61.5ms max 86.6ms: 38.1285 MB/s38.4339 MB/s, 62.2us access timebytes 512, time 408248 overhead 332736bytes 1024, time 438602 overhead 349769bytes 2048, time 466362 overhead 350886bytes 4096, time 534532 overhead 365769bytes 8192, time 633148 overhead 357813bytes 16384, time 906074 overhead 417593bytes 32768, time 1342443 overhead 427672bytes 65536, time 2197584 overhead 430232bytes 131072, time 3344490 overhead -128025bytes 262144, time 6216344 overhead -666496bytes 524288, time 11780814 overhead -1.92268e+06bytes 1048576, time 27688070 overhead 343282bytes 2097152, time 55002223 overhead 374836
program
~ # flashbench -p /dev/mmcblk02MiB 7.62M/s 10.3M/s 12.1M/s 35.4M/s 6.02M/s 7.71M/s 7.6M/s 38M/s 1MiB 11.4M/s 13.3M/s 13.3M/s 38.2M/s 6.21M/s 7.68M/s 7.66M/s 37.5M/s 512KiB 16.6M/s 16.7M/s 16.7M/s 37.9M/s 7.63M/s 4.83M/s 5.2M/s 37M/s 256KiB 15.3M/s 16.1M/s 16.1M/s 36.3M/s 2.68M/s 1.22M/s 1.16M/s 36.6M/s 128KiB 14.4M/s 14.9M/s 14.8M/s 34.4M/s 2.17M/s 1.67M/s 1.68M/s 33.8M/s 64KiB 12.9M/s 13M/s 13.1M/s 30.3M/s 1.27M/s 1.04M/s 1.05M/s 29.8M/s 32KiB 11M/s 11M/s 10.9M/s 24.5M/s 476K/s 441K/s 438K/s 24.1M/s 16KiB 9.93M/s 9.92M/s 9.96M/s 18M/s 273K/s 253K/s 247K/s 17.8M/s 8KiB 3.74M/s 3.75M/s 3.75M/s 11.6M/s 3.8M/s 3.82M/s 3.82M/s 11.5M/s 4KiB 1.52M/s 1.6M/s 1.6M/s 6.8M/s 1.92M/s 1.93M/s 1.92M/s 6.73M/s 2KiB 604K/s 683K/s 683K/s 3.71M/s 980K/s 979K/s 979K/s 3.67M/s 1KiB 246K/s 273K/s 273K/s 1.94M/s 470K/s 469K/s 472K/s 1.91M/s 512B 264K/s 286K/s 286K/s 1.04M/s 243K/s 243K/s 244K/s 1.04M/s
第一列代表每次读写文件的大小，测试的原理是写4M的文件，对于2M的大小，测试两次，对于1M的大小，测试4次，依次类推。
后面的几列依次是linear write zeros, linear write ones, linear write 0x5a, linear read,
random write zeros, random write ones, random write 0x5a, random read的速度
补充一下：
线性读写：每次读写完N字节后，偏移也加N字节，然后从偏移处继续读写，这样写指针在进行新的一次读写的时候不需要移动。
随机位置读写：写完上一笔数据后，重新移动写指针到别的某个位置，然后在进行一次新的读写。
随机内容读写：写的内容是随机的内容，这个对读写速度的测试不影响。
随机位置读写由于要重新移动写指针，而线性读写不需要移动写指针，所以随机位置的读写速度明显要比线性读写的速度慢。
通过dd测试sd卡读写速度
使用dd命令来测试sd卡读写速度，测试内容如下：
从图中可以看出来，在输入分别为/dev/zero，/dev/random， /dev/urandom，写卡的速度是有很大差别的，与上面使用flashbench测试随机写1M文件的速度25.2M/s相比小很多，看起来dd测试速度的时候将读取输入的时间也算在内了，所以速度相对来说小很多，而且在读取/dev/zero，/dev/random， /dev/urandom这3个不同的输入的时间的差别也相差很大。
所以，dd测试速度的时候将读取输入的时间也算在内了，使用dd测试sd卡速度是不够准确的。
通过dd测试sd卡真实容量
Create a file with the required capacity, filled with random data. We’re writing blocks of 1024 bytes, so adjust the count to the capacity required (16GB in my case).
dd if=/dev/urandom of=rnd_init_data bs=1024 count=16000000
Now, we write the data to the SD card.
$ dd if=rnd_init_data of=/dev/sdb bs=1024 count=1600000015558145+0 records in15558144+0 records out15931539456 bytes (16 GB) copied, 536.286 s, 29.7 MB/s
You can see, we didn’t manage to write all the bytes to the card. This is expected, as we don’t know the capacity of the card down to the last byte. As long as the capacity reported by dd (16 GB) is close to the expected result, we’re happy.
Now, we copy the bytes written to a new file, which we use for later comparison. Notice here the count, which we adapted to the bytes written to the card (15931539456 / 1024 = 15558144). I am sure this can be done easier using tools like truncate, but I didn’t want to start messing with programs that I don’t know by heart.
$ dd if=rnd_init_data of=rnd_written_data bs=1024 count=15558144$ rm -f rnd_init_data
Read back the data from the card:
$ dd if=/dev/sdb of=rnd_read_data bs=1024 count=15558144
Finally, we’re comparing the two data files:
$ md5sum rnd*dfed784abed6662926eb01f7fb5359ca rnd_written_datadfed784abed6662926eb01f7fb5359ca rnd_read_data
通过fio测试sd卡读写速度
使用fio命令测试sd卡读写速度，测试命令
读：fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=read随机读：fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=randread写：fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=write随机写：fio -filename=/dev/mmcblk0 -direct=1 -numjobs=1 -thread -group_reporting -ioengine=psync -iodepth=1 -size=4M -name=mytest -bs=1M -rw=randwrite
测试的结果与使用flashbench测试结果对比如下：
fio所测试的速度相对flashbench所测试的速度稍微慢一点，在合理的偏差范围内，但基本的速度随着读写文件的大小变化情况是一致的。
