tkaiser Posted April 5, 2016 Posted April 5, 2016 Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations. Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance. Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there) Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/ Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread. Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast. Preparations: I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected). Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot). Sequential speeds: Random I/O: The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run) Sequential speed mostly irrelevant / random I/O differs and matters a lot! The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s). Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot. All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes. Detailed results (summary table also available as .ods, .xlsx or .txt): Samsung Pro 64GB (brand new) http://sprunge.us/DEYd ext4: random random kB reclen write rewrite read reread read write 102400 4 1399 2709 4927 8189 7752 2463 102400 16 7132 7288 13872 13893 13906 6461 102400 512 21500 21548 22515 22512 22512 21541 102400 1024 21874 21968 22650 22651 22649 21998 102400 16384 22052 22088 22847 22849 22849 22069 102400 4 2800 3017 8114 8119 8077 2484 102400 16 6970 7336 13877 13884 13879 6531 102400 512 21363 21549 22582 22459 22585 21525 102400 1024 21998 22016 22767 22764 22763 22077 102400 16384 22126 22186 22910 22904 22908 22239 102400 4 3248 3066 8244 8277 8244 2493 102400 16 6958 7333 13873 13880 13873 6519 102400 512 21692 21805 22749 22771 22761 21820 102400 1024 22105 22223 22848 22864 22854 22102 102400 16384 22214 22224 22916 22923 22919 22150 102400 4 3273 3056 8209 8220 8166 2501 102400 16 6976 7325 13861 13885 13859 6544 102400 512 21540 21611 22713 22710 22725 21576 102400 1024 21958 22048 22792 22797 22785 21976 102400 16384 22090 22100 22904 22919 22928 22140 f2fs: 102400 4 1983 2007 8068 8064 8052 1756 102400 16 7657 7381 13862 13853 13856 6112 102400 512 21451 21743 22586 22595 22588 21707 102400 1024 21927 22197 22727 22732 22721 22167 102400 16384 22058 22324 22899 22911 22917 22268 data: cid: 1b534d303030303010a2b8063800f96b csd: 400e00325b590001dcff7f800a4040f1 scr: 02c5800300000000 date: 09/2015 name: 00000 type: SD preferred_erase_size: 16777216 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0xa2b80638 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512 Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd ext4: random random kB reclen write rewrite read reread read write 102400 4 3058 3033 6918 6840 6922 3191 102400 16 10003 10559 14591 14567 14576 10803 102400 512 21211 21276 22643 22623 22635 21341 102400 1024 21534 21604 22792 22793 22792 21614 102400 16384 21659 21670 22885 22885 22885 21692 102400 4 3207 3250 7515 7523 7525 3383 102400 16 11107 12030 14602 14593 14609 12043 102400 512 21334 21384 22758 22758 22758 21451 102400 1024 21644 21655 22876 22876 22875 21748 102400 16384 21700 21711 22944 22944 22948 21735 102400 4 3263 3334 7518 7526 7527 3389 102400 16 11146 12026 14604 14594 14608 12049 102400 512 21187 21251 22609 22613 22588 21260 102400 1024 21506 21590 22698 22700 22699 21594 102400 16384 21703 21703 22929 22933 22934 21728 102400 4 3304 3343 7517 7524 7522 3415 102400 16 11207 12132 14600 14596 14608 12145 102400 512 21312 21373 22736 22734 22736 21432 102400 1024 21641 21701 22885 22885 22882 21768 102400 16384 21657 21726 22949 22949 22948 21744 f2fs: 102400 4 3407 3347 7524 7530 7516 3450 102400 16 8268 9925 14593 14599 14600 11123 102400 512 13853 14986 22775 22784 22776 20936 102400 1024 14572 15736 22870 22877 22875 20985 102400 16384 15575 15950 22894 22936 22938 17145 data: cid: 1b534d3030303030105dd7045000fb33 csd: 400e00325b590001dcff7f800a4040f1 scr: 02c5800300000000 date: 11/2015 name: 00000 type: SD preferred_erase_size: 16777216 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0x5dd70450 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512 Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL ext4: random random kB reclen write rewrite read reread read write 102400 4 2978 3168 7502 7508 7507 3146 102400 16 10791 12151 14592 14582 14597 12226 102400 512 21375 21403 22810 22812 22807 21491 102400 1024 21677 21664 22879 22881 22877 21768 102400 16384 21681 21679 22948 22943 22946 21709 102400 4 3316 3387 7496 7503 7506 3434 102400 16 10749 12226 14589 14580 14596 12246 102400 512 21408 21425 22817 22822 22817 21549 102400 1024 21620 21742 22927 22928 22925 21782 102400 16384 21681 21717 22892 22892 22892 21677 102400 4 3333 3366 7500 7507 7504 3443 102400 16 11403 12253 14587 14580 14595 12306 102400 512 21426 21442 22850 22847 22848 21527 102400 1024 21680 21729 22917 22921 22923 21796 102400 16384 21641 21677 22894 22892 22894 21694 102400 4 3346 3414 7486 7505 7506 3453 102400 16 11434 12306 14592 14582 14598 12334 102400 512 21321 21407 22711 22716 22710 21474 102400 1024 21648 21627 22808 22854 22855 21707 102400 16384 21772 21734 22949 22950 22949 21723 f2fs: 102400 4 3350 3423 7498 7504 7492 3514 102400 16 9465 9818 14580 14588 14587 9107 102400 512 13910 15319 22706 22710 22706 20576 102400 1024 14776 16229 22855 22858 22853 20642 102400 16384 15859 16209 22917 22934 22935 18968 data: cid: 1b534d30303030301049fb02a300fc63 csd: 400e00325b590000ee7f7f800a404055 scr: 02b5800200000000 date: 12/2015 name: 00000 type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0x49fb02a3 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512 Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS ext4: random random kB reclen write rewrite read reread read write 102400 4 3233 3339 7547 7557 7561 3392 102400 16 11326 12256 14628 14618 14636 12237 102400 512 21248 21333 22682 22684 22680 21402 102400 1024 21487 21640 22805 22806 22805 21688 102400 16384 21747 21756 22938 22940 22939 21798 102400 4 3358 3414 7545 7557 7561 3470 102400 16 10393 12281 14626 14635 14632 12304 102400 512 21265 21407 22637 22636 22633 21425 102400 1024 21614 21653 22790 22789 22790 21743 102400 16384 21747 21689 22889 22888 22888 21679 102400 4 3353 3406 7546 7556 7561 3475 102400 16 11348 12306 14628 14620 14636 12312 102400 512 21288 21388 22696 22700 22690 21444 102400 1024 21662 21634 22852 22854 22852 21753 102400 16384 21715 21745 22891 22892 22890 21775 102400 4 3338 3405 7546 7544 7557 3463 102400 16 11377 12253 14623 14608 14636 12248 102400 512 21325 21426 22728 22729 22723 21443 102400 1024 21625 21702 22799 22800 22790 21701 102400 16384 21757 21737 22943 22943 22943 21789 f2fs: 102400 4 3347 3411 7534 7544 7527 3514 102400 16 8995 9460 14613 14618 14620 9751 102400 512 14407 15388 22844 22850 22844 21201 102400 1024 14251 15997 22934 22940 22937 20626 102400 16384 15878 16186 22936 22942 22931 17273 data: cid: 1b534d3030303030104030047600fc11 csd: 400e00325b590001dcff7f800a4040f1 scr: 02c5800300000000 date: 12/2015 name: 00000 type: SD preferred_erase_size: 16777216 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0x40300476 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512 SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ ext4: random random kB reclen write rewrite read reread read write 102400 4 2828 2886 8380 8376 8357 1250 102400 16 11725 11702 15923 15901 14903 3242 102400 512 20692 20061 22835 22829 22808 3078 102400 1024 19709 21215 22881 22881 22867 5981 102400 16384 19986 21296 22959 22956 22956 21269 102400 4 2830 2939 8442 8439 8170 1277 102400 16 11471 12395 15995 15996 15905 3337 102400 512 19761 21076 22852 22849 22833 3058 102400 1024 20702 20241 22913 22908 22899 5985 102400 16384 21009 20231 22961 22961 22960 21275 102400 4 2901 3010 8421 8428 8152 1275 102400 16 11453 12369 15976 15985 15924 3350 102400 512 19662 20955 22671 22663 22649 3053 102400 1024 20664 20204 22855 22852 22847 5982 102400 16384 21006 20243 22958 22955 22955 21270 102400 4 2903 3026 8442 8448 8184 1274 102400 16 11450 12393 16004 16010 15931 3347 102400 512 19682 20997 22695 22693 22678 3056 102400 1024 20715 20246 22931 22926 22921 5987 102400 16384 21008 20250 22965 22962 22963 21262 f2fs: 102400 4 3028 3047 8201 8216 8128 1300 102400 16 12319 12488 15882 15882 15844 3247 102400 512 19908 20613 22699 22707 22705 3263 102400 1024 19587 20926 22908 22921 22915 5699 102400 16384 19627 20854 22941 22952 22953 18046 data: ### mmc0:e624 info: cid: 0353445355303847801013315600d69b csd: 400e00325b5900003b377f800a4040af scr: 0235800300000000 date: 06/2013 name: SU08G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x8 oemid: 0x5344 manfid: 0x000003 serial: 0x10133156 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SU08G MODALIAS=mmc:block erase_size: 512 SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT ext4: random random kB reclen write rewrite read reread read write 102400 4 2221 2258 7937 7938 7920 789 102400 16 6762 7252 15545 15582 14623 107 102400 512 7663 11468 22813 22814 22752 2803 102400 1024 8429 11789 22942 22943 22938 4926 102400 16384 9314 10608 22932 22931 22932 10470 f2fs: not worth to measure data: cid: 035344534c30384780437635a900f78f csd: 400e00325b5900003b377f800a4040af scr: 0235800100000000 date: 07/2015 name: SL08G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x8 oemid: 0x5344 manfid: 0x000003 serial: 0x437635a9 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SL08G MODALIAS=mmc:block erase_size: 512 Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ ext4: random random kB reclen write rewrite read reread read write 102400 4 1794 1828 7211 7212 6085 465 102400 16 6378 6298 12541 12536 11668 32 102400 512 10247 10126 22126 21508 22036 1040 102400 1024 10529 10114 22403 22404 21260 2072 102400 16384 10800 10366 22544 22545 22543 8896 f2fs: not worth to measure data: cid: 2750485344313647300133870f00e5e1 csd: 400e00325b590000734f7f800a40001b scr: 0235800301000000 date: 05/2014 name: SD16G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x3 oemid: 0x5048 manfid: 0x000027 serial: 0x0133870f uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SD16G MODALIAS=mmc:block erase_size: 512 Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY ext4: random random kB reclen write rewrite read reread read write 102400 4 1272 1303 7799 7865 6380 140 102400 16 5270 5177 10395 10398 9655 37 102400 512 9054 9713 15676 15727 15673 1199 102400 1024 9199 9988 15878 15878 15847 2332 102400 16384 9837 9640 15924 14124 15921 8077 f2fs: not worth to measure data: cid: 27504853443447423001b280db00f2fd csd: 400e00325b5900001da77f800a40002d scr: 0235800001000000 date: 02/2015 name: SD4GB type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x3 oemid: 0x5048 manfid: 0x000027 serial: 0x01b280db uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SD4GB MODALIAS=mmc:block erase_size: 512 Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter): Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD ext4: random random kB reclen write rewrite read reread read write 102400 4 2410 2501 6895 6892 6450 1553 102400 16 5530 5882 15385 15388 15056 2845 102400 512 11266 11187 22825 22825 22696 10355 102400 1024 12479 12674 22950 22952 22937 10549 102400 16384 12547 12928 22961 22962 22961 11600 102400 4 2369 2533 6837 6837 6713 1344 102400 16 5739 7179 15224 15254 14952 3906 102400 512 11598 12743 22810 22814 22698 9600 102400 1024 11270 11806 22924 22927 22819 9872 102400 16384 11796 11779 22966 22964 22937 11117 data: cid: 744a45555344553110458a05ea00eb79 csd: 400e00325b59000075cd7f800a4000c1 scr: 0235800300000000 date: 11/2014 name: USDU1 type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x1 oemid: 0x4a45 manfid: 0x000074 serial: 0x458a05ea uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=USDU1 MODALIAS=mmc:block erase_size: 512 Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ ext4: random random kB reclen write rewrite read reread read write 102400 4 2750 2872 8381 8380 8162 1241 102400 16 11780 12351 16092 16094 15059 3070 102400 512 20417 20061 22846 22844 22818 3025 102400 1024 19764 21301 23003 23004 22992 5912 102400 16384 19963 21291 22965 22962 22961 21269 102400 4 3000 3128 8375 8376 7938 1254 102400 16 11410 12340 16058 16062 15964 3202 102400 512 20292 20962 22710 22710 22690 3003 102400 1024 19709 21204 22888 22885 22879 5907 102400 16384 19959 21289 22959 22958 22960 21262 102400 4 2909 3042 8383 8386 8109 1251 102400 16 11399 12348 16081 16078 16039 3184 102400 512 20427 21082 22894 22891 22863 3004 102400 1024 19738 21260 22945 22947 22929 5910 102400 16384 19946 21283 22963 22969 22963 21272 data: cid: 0353445355303847800fa814ae00eb5f csd: 400e00325b5900003b377f800a4040af scr: 0235800300000000 date: 11/2014 name: SU08G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x8 oemid: 0x5344 manfid: 0x000003 serial: 0x0fa814ae uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SU08G MODALIAS=mmc:block erase_size: 512 Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF ext4: random random kB reclen write rewrite read reread read write 102400 4 11485 12921 7044 7060 7010 11957 102400 16 17668 19117 17584 17579 17467 16706 102400 512 22711 22641 22962 22967 22942 21219 102400 1024 22800 22871 23056 23054 23041 22737 102400 16384 22803 22852 22990 22989 22989 22764 102400 4 11412 13181 7072 7085 7026 12612 102400 16 17577 17969 17587 17616 17482 18382 102400 512 22683 22809 22959 22956 22933 22360 102400 1024 21974 22807 22975 22979 22945 22645 102400 16384 22815 22832 22983 22984 22982 22800 102400 4 11367 13001 7073 7090 7033 12933 102400 16 17841 17579 17486 17522 17387 18909 102400 512 22635 22716 22875 22875 22848 22509 102400 1024 22602 22713 22967 22964 22946 22657 102400 16384 22762 22766 22986 22985 22984 22763 data: cid: 15010038474e44335201b5c3406d13c7 csd: d02701320f5903fff6dbffef8e40400d prv: 0x1 date: 01/2016 name: 8GND3R type: MMC rel_sectors: 0x1 preferred_erase_size: 524288 fwrev: 0x0100000000000000 hwrev: 0x0 oemid: 0x0100 enhanced_area_offset: 18446744073709551594 ffu_capable: 1 raw_rpmb_size_mult: 0x4 manfid: 0x000015 serial: 0xb5c3406d uevent: DRIVER=mmcblk MMC_TYPE=MMC MMC_NAME=8GND3R MODALIAS=mmc:block erase_size: 524288 enhanced_area_size: 4294967274 Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf ext4: random random kB reclen write rewrite read reread read write 102400 4 1353 1378 7139 7139 7127 687 102400 16 7825 7565 14797 14815 13876 54 102400 512 12511 14238 22759 22760 22691 1717 102400 1024 12623 14502 22917 22918 22878 3474 102400 16384 14251 13622 22925 22927 22923 14273 data: cid: 03534453553038478004add48400cc2b csd: 400e00325b5900003b377f800a4040af scr: 0235800100000000 date: 12/2012 name: SU08G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x8 oemid: 0x5344 manfid: 0x000003 serial: 0x04add484 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SU08G MODALIAS=mmc:block erase_size: 512 Sandisk 8GB (almost new) http://sprunge.us/iViT ext4: random random kB reclen write rewrite read reread read write 102400 4 2230 2207 7700 7700 7697 784 102400 16 6793 7338 15329 15352 14718 107 102400 512 8931 10596 22591 22595 22588 2741 102400 1024 9541 11083 22799 22796 22797 4491 102400 16384 9944 10954 22926 22929 22861 11421 102400 4 2356 2232 7793 7795 7773 750 102400 16 7570 7320 15445 15458 15445 109 102400 512 9057 10621 22734 22736 22688 2802 102400 1024 8573 10944 22827 22827 22789 5271 102400 16384 9400 11379 22922 22925 22923 10981 102400 4 2335 2375 7774 7773 7766 764 102400 16 7314 7066 15413 15431 15377 108 102400 512 8610 11666 22744 22742 22736 2718 102400 1024 8684 11466 22934 22934 22929 5547 102400 16384 9369 11400 22931 22934 22930 10761 data: cid: 035344534c303847804376351700f7db csd: 400e00325b5900003b377f800a4040af scr: 0235800100000000 date: 07/2015 name: SL08G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x8 oemid: 0x5344 manfid: 0x000003 serial: 0x43763517 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SL08G MODALIAS=mmc:block erase_size: 512 Sandisk 8G (new) http://sprunge.us/XHjj ext4: random random kB reclen write rewrite read reread read write 102400 4 1790 1849 8530 8527 8354 876 102400 16 7343 7431 16423 16456 15852 52 102400 512 12041 13073 22596 22596 22552 1652 102400 1024 12172 13216 22805 22807 22791 3319 102400 16384 13069 13276 22943 22943 22941 12862 102400 4 1954 2007 8586 8587 7975 876 102400 16 7331 7569 16417 16440 16364 52 102400 512 12179 13225 22738 22737 22726 1666 102400 1024 12312 13423 22949 22948 22943 3348 102400 16384 13184 13435 22952 22952 22952 13050 102400 4 1857 1914 8577 8579 8539 886 102400 16 7387 7649 16497 16526 16446 52 102400 512 12067 13103 22839 22846 22838 1650 102400 1024 12155 13263 22982 22985 22979 3315 102400 16384 13067 13240 22952 22954 22954 12874 data: cid: 035344534c3038478043a20b9a0103d7 csd: 400e00325b5900003b377f800a4040af scr: 0235800100000000 date: 03/2016 name: SL08G type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x8 oemid: 0x5344 manfid: 0x000003 serial: 0x43a20b9a uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SL08G MODALIAS=mmc:block erase_size: 512 Transcend 8Gb (used) http://sprunge.us/NTRT ext4: random random kB reclen write rewrite read reread read write 102400 4 2190 2201 7646 7678 7279 780 102400 16 3705 5449 15554 15558 15410 1786 102400 512 6653 7261 20779 20847 20833 4779 102400 1024 7172 7548 20954 20951 20944 5887 102400 16384 7242 7138 20800 20937 20937 6983 102400 4 2259 2372 7645 7651 7529 841 102400 16 5418 6149 15722 15718 15509 2907 102400 512 6742 7474 20737 20812 20801 4822 102400 1024 7115 7074 20816 20881 20869 5988 102400 16384 6808 7155 20925 20953 20947 7255 data: cid: 744a45555344202002c9409e2f00ec63 csd: 400e00325b5900003bcd7f800a400041 scr: 0235800100000000 date: 12/2014 name: USD type: SD preferred_erase_size: 4194304 fwrev: 0x2 hwrev: 0x0 oemid: 0x4a45 manfid: 0x000074 serial: 0xc9409e2f uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=USD MODALIAS=mmc:block erase_size: 512 Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh ext4: random random kB reclen write rewrite read reread read write 102400 4 2886 3256 7620 7627 7625 3419 102400 16 9870 10306 14685 14672 14687 9314 102400 512 21362 21398 22755 22758 22752 21462 102400 1024 21631 21666 22829 22832 22832 21719 102400 16384 21746 21789 22942 22944 22942 21768 102400 4 2675 3354 7636 7640 7641 3219 102400 16 11198 12135 14696 14688 14703 12177 102400 512 21368 21399 22773 22773 22766 21478 102400 1024 21639 21647 22852 22853 22853 21752 102400 16384 21665 21718 22902 22900 22900 21725 102400 4 3308 3373 7629 7639 7590 3433 102400 16 10232 12149 14696 14687 14700 12176 102400 512 21427 21458 22846 22850 22845 21565 102400 1024 21638 21727 22857 22857 22856 21726 102400 16384 21773 21742 22955 22952 22953 21729 data: cid: 1b534d3030303030107d4655c801022d csd: 400e00325b590000ee7f7f800a404055 scr: 02b5800200000000 date: 02/2016 name: 00000 type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0x7d4655c8 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512 Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions: If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card 9
Code4Sale LLC Posted April 11, 2016 Posted April 11, 2016 Excellent! Thanks so much for the effort! 2
tkaiser Posted April 11, 2016 Author Posted April 11, 2016 You're welcome. And might be able to improve the collection of quality cards: http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/ I'm especially interested in results from smaller cards (8GB, 16GB) and more recent SanDisk Extreme Pro/Plus. 1
technik007_cz Posted April 13, 2016 Posted April 13, 2016 Toshiba Memory Exceria M301 8GB MicroSDXC Class 10 48 Mbps http://sprunge.us/bSfN brand new card, result of 3rd test Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 637 629 7416 7420 6402 611 102400 16 6997 7375 10210 10654 10091 63 102400 512 16026 15845 22069 22070 21991 2022 102400 1024 16468 16261 22488 22488 22443 4027 102400 16384 16558 16217 22443 22442 22440 12880 1
technik007_cz Posted April 13, 2016 Posted April 13, 2016 Samsung Memory 32 GB EVO http://sprunge.us/NVTg brand new card, it should be 10th test (i cannot scroll it up) Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 3365 3419 7577 7589 7588 3483 102400 16 11342 12297 14648 14640 14654 12303 102400 512 21408 21468 22814 22814 22814 21464 102400 1024 21654 21708 22871 22866 22869 21764 102400 16384 21703 21737 22950 22948 22949 21786
technik007_cz Posted April 14, 2016 Posted April 14, 2016 Kingston 16GB Micro SDHC Card 90 MB/s UHS-I U3 + Adapter - Class 10 used card Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 710 705 9292 9296 7777 685 102400 16 8510 8595 11731 12567 11787 72 102400 512 20311 19950 22217 22220 22144 2185 102400 1024 19277 20341 22538 22540 22497 4330 102400 16384 20925 20539 22575 22574 22572 15891 /var/log/armhwinfo.log has been uploaded to http://sprunge.us/Lihf EDIT: second run, same card random random kB reclen write rewrite read reread read write 102400 4 712 698 9286 9285 7804 686 102400 16 8444 8633 11652 12562 11775 72 102400 512 20264 19939 22124 22126 22040 2187 102400 1024 19252 20345 22474 22475 22433 4302 102400 16384 20934 20526 22566 22568 22564 15537
tkaiser Posted April 15, 2016 Author Posted April 15, 2016 In this 'Let's start a collective benchmark' thread might appear a few other results (and 4 cards are already there that are missing here): But IMO we can already sum it up: On boards that only implement the slowest SDIO mode (4 bit @ 50 MHz) the SDIO interface between SoC and SD card becomes the bottleneck when we're talking about sequential transfer speeds. You won't exceed ~23MB/s anyway. Therefore choosing cards where sequential write/read exceed this treshold is somewhat useless unless you use them also somewhere else where the host is capable of higher speeds (this was one of my former use cases: burning OS images in minimum time with +80 MB/s on my laptop -- now mostly irrelevant since FEL/NFS booting is way more fast and convenient when it's about testing new Armbian images) Many 'normal' SanDisk, Toshiba and Transcend cards aren't that fast and show a strange random I/O write weakness with 16k record size (does not apply to the more/most expensive series from the same vendors!) The speed differences when we're talking about small record sizes (the typical card accesses when you put your rootfs or user homes on SD card) vary a lot, especially when it's about random I/O and especially random writes To my surprise the rather cheap Samsung EVOs in our scenario were as fast as the more expensive EVO+ (these show higher potential sequential performance you can't make use of if the SDIO implementation is already the bottleneck) and outperform the even more expensive Samsung Pros in most areas. The EVO's sequential write speeds are advertised as '10 MB/s' but in reality that's something +20 MB/s at least with the few samples we tested with The top performer was Hardkernel's eMMC module combined with their Micro SD adapter. Sequential transfer speeds limited as with the others but random I/O simply rocks. You get what you pay for Things to mention: Boards exist that do not share the slow SDIO limitation as our test boards using Allwinner's A20. On these random I/O might be nearly identical but the sequential speed limitation of ~22/23 MB/s isn't existent. With these boards you might see huge differences when using more expensive branded cards as long as we're talking about sequential transfer speeds (writing/reading huge amounts of data constantly) Regarding more recent SoCs you always have to differentiate between SoC and implementation/board. For example Allwinner's cheap 64-bit A64 is able to use the faster SDIO modes. But on cheap boards like Pine64 this isn't implemented (requires on-the-fly voltage switching between 3.3V and 1.8V for the faster modes). A64 is also able to access eMMC which could be magnitudes faster than SD cards. But since some of the needed eMMC pins are already used for other stuff on the Pine64 you're limited to the slowest SDIO access mode (which also means: all performance numbers above are valid for Pine64 -- I did some cross checks to confirm) Please keep in mind that the Kingston results above as well as all results for cheap 'normal' SanDisk, Toshiba or Transcend cards are hard to interpret. Kingston buys flash chips and controllers on spot markets and combines whatever is cheap at the moment. Therefore you get the irrelevant sequential speeds as advertised but random I/O might vary between different batches a lot (please remember: On SBCs random I/O is more important) Same applies to the cheap SanDisk, Toshiba and Transcend cards, especially if the tested cards are a few years old. Chances are great that you now get a card that is labeled identical but features both a new controller and new NAND chips that are many times faster when we're talking about random I/O Always remember that there are a few renowned storage brands that just buy bunches of unknown flash chips to combine them with unknown controllers. Both performance and reliability might vary a lot between different batches Then there exist manufacturers that own NAND factories, produce their own controllers, have engineers that do not just think about optimal combinations but realize them and ship final products. Think about the difference to the aforementioned group when buying cards And finally... reliability: You read all of the above and thought 'Well, what can be wrong ordering 5 of these cheap and performant EVO?' Maybe, that you get something different. Fraud/counterfeit cards are still a massive problem, so always test any card you buy directly after purchase. Always! No excuses! It's really easy and worth the efforts (more info) What about longevity? SD cards were made for cameras/recorders (sequential transfers, access pattern: mostly idle). This is an absolutely different use case than using these cards with an SBC, especially when a lot of random I/O happens (Armbian already helps here with a rather high commit interval: with our defaults all disk related changes are collected and then written to the card just every 10 minutes) I talked recently to someone who deploys lots of devices built of SBCs relying on SD cards. His conclusion: Never ever buy anything again but SanDisk Extreme Plus (not Pro -- yes, those that are twice as expensive ). The costs to replace a broken card at a customer's location are many times higher than buying reliable hardware in the beginning What to do if this is not your situation but you still care about reliability/longevity? You can try to do burn-in tests (maybe lasting a few months/years of continual random writes/reads and results with no meaning since the manufacturer exchanged the controller and/or NAND dies in the meantime) or you take the trust the vendor has into his own products into account. Choosing cards with a warranty of 10 years or even more is not the worst choice in such a situation. 1
zador.blood.stained Posted April 15, 2016 Posted April 15, 2016 In this 'Let's start a collective benchmark' thread might appear a few other results (and 4 cards are already there that are missing here): As a moderator you should be able to move single messages from one topic to another. Armbian already helps here with a rather high commit interval: with our defaults all disk related changes are collected and then written to the card just every 10 minutes Unless software explicitly bypasses cache for writing. Choosing cards with a warranty of 10 years or even more is not the worst choice in such a situation. SSH keys, (almost) plaintext passwords and other stuff is not something you want to give to someone if card becomes read-only and you can't erase any data without physically damaging the card (or using high voltage).
tkaiser Posted April 20, 2016 Author Posted April 20, 2016 As a moderator you should be able to move single messages from one topic to another. SSH keys, (almost) plaintext passwords and other stuff is not something you want to give to someone if card becomes read-only and you can't erase any data without physically damaging the card (or using high voltage). As a moderator I already created so much mess that I better stay away from this People are also continually submitting new results in the other thread so we should try to use this thread here for drawing conclusions (one below). And you're right: Returning a used/read-only SSD card if you're not allowed to totally destroy it is not a good idea if it contains sensitive data. But I spoke more about the amount of trust a vendor has in his own products if he gives you a 10 year warranty. Some interesting EVO/EVO+ performance comparisons One interesting conclusion can already be drawn: It's already known that better SD card controllers use parallelism. In case there are enough NAND dies used on the card, a good controller starts to implement stuff known as RAID-0 from disks. Reading/writing in parallel to different NAND chips which increases performance. In the meantime we got results for Samsung EVO and EVO+ of all sizes up to 64 GB. And it seems the magical size limit is 32GB: Samsung EVO 8GB (02/2015) random random kB reclen write rewrite read reread read write 102400 4 2200 1566 6410 6683 6164 904 102400 16 6012 7033 14437 14704 14169 2649 102400 512 7962 9815 21489 21360 20575 4009 102400 1024 9289 13453 22043 22037 21919 6692 102400 16384 11469 11671 22836 22869 22823 11764 Samsung EVO 16GB (10/2015) random random kB reclen write rewrite read reread read write 102400 4 2310 2299 6679 6674 6562 1310 102400 16 6313 6716 15062 15140 14668 3962 102400 512 9232 11316 22431 22425 22291 9952 102400 1024 10457 12193 22704 22703 22568 9447 102400 16384 10818 12223 22712 22713 22662 11409 Samsung EVO 32GB (02/2016) random random kB reclen write rewrite read reread read write 102400 4 3308 3373 7629 7639 7590 3433 102400 16 10232 12149 14696 14687 14700 12176 102400 512 21427 21458 22846 22850 22845 21565 102400 1024 21638 21727 22857 22857 22856 21726 102400 16384 21773 21742 22955 22952 22953 21729 Samsung EVO PLUS 32GB (12/2015) random random kB reclen write rewrite read reread read write 102400 4 3346 3414 7486 7505 7506 3453 102400 16 11434 12306 14592 14582 14598 12334 102400 512 21321 21407 22711 22716 22710 21474 102400 1024 21648 21627 22808 22854 22855 21707 102400 16384 21772 21734 22949 22950 22949 21723 Samsung EVO 64GB (12/2015) random random kB reclen write rewrite read reread read write 102400 4 3338 3405 7546 7544 7557 3463 102400 16 11377 12253 14623 14608 14636 12248 102400 512 21325 21426 22728 22729 22723 21443 102400 1024 21625 21702 22799 22800 22790 21701 102400 16384 21757 21737 22943 22943 22943 21789 Samsung EVO PLUS 64GB (12/2015) random random kB reclen write rewrite read reread read write 102400 4 3304 3343 7517 7524 7522 3415 102400 16 11207 12132 14600 14596 14608 12145 102400 512 21312 21373 22736 22734 22736 21432 102400 1024 21641 21701 22885 22885 22882 21768 102400 16384 21657 21726 22949 22949 22948 21744 The EVO and EVO+ we tested do not perform different since they would only differ regarding higher sequential speeds if the SBC's SDIO implementation wouldn't already be the bottleneck. So spending more money for an EVO+ when used with these sorts of SBCs is useless. More interestingly random I/O is also identical if the card's capacity is 32GB or higher (due to parallelism, see before). Same can be seen when it's about sequential writes: EVOs with less than 32GB seem to use only one NAND die while on the 32GB model data will be written to two in parallel which leads to twice the throughput. Therefore choosing an EVO with 32GB capacity will lead to better overall storage performance than when choosing one with smaller capacity (beware: that does only apply to EVOs or in general: cards that have been tested thoroughly. No conclusions can be drawn regarding no-name cards, Kingston, PNY and the like since you never know which controllers they use in a specific production batch). It would be interesting how a 16GB EVO+ behaves (maybe using more parallelism and showing higher random I/O and sequential writes than a 16GB EVO). But given the low prices for these cards today I would simply choose a 32GB and enjoy 15 GiB more useable capacity.
rufik Posted April 26, 2016 Posted April 26, 2016 You're writing about SD card speed but what about reliability? Is eMMC more reliable than SD card (ex. Samsung EVO)?
tkaiser Posted April 26, 2016 Author Posted April 26, 2016 You're writing about SD card speed but what about reliability? Is eMMC more reliable than SD card (ex. Samsung EVO)? Well, I talked about realibility already -- please see above. At least with onboard eMMC you can't get fraud flash storage as it's pretty common with SD/TF cards. And regarding longevity/reliability I would assume it depends on the use case. If you constantly have to write large amounts of random data to media better consider using SD cards in this scenario (since it's a bit challenging to replace onboard eMMC compared to switching SD cards ) In case I would have to put data of value on any media I always try to fight data corruption (using ZFS or btrfs and periodic scrubbing and also sending snapshots to another device to have a safe backup)
sysitos Posted July 19, 2016 Posted July 19, 2016 Some quick test with f3write on eMMC on Orange Pi+ 2E. Writing speed starts with excellent 24MB/s. After approx. 3GB written data the writing rate drops nearly instantly to 7,5 MB/s and stays for it until the end of the 12GB. Any clue why this happens? Reading rate is about 60MB/s, not so bad.
tkaiser Posted July 20, 2016 Author Posted July 20, 2016 Writing speed starts with excellent 24MB/s. After approx. 3GB written data the writing rate drops nearly instantly to 7,5 MB/s and stays for it until the end of the 12GB. 24MB/s is not that much or in other words: An indication that F3 uses rather small block sizes. Please compare with post #45 and #48 here: http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/?p=9886 Would be interesting if it's a thermal issue or not (I had the same issues on Beelink X2's eMMC way early)
Ford Prefect Posted July 20, 2016 Posted July 20, 2016 I think it is because to move data you first write it in RAM and Linux uses all the available RAM for it. In that case at the beginning the writing speed is lying in fact it is reading speed. That behavior was quite surprising when writing on floppy disks.
tkaiser Posted July 20, 2016 Author Posted July 20, 2016 I think it is because to move data you first write it in RAM and Linux uses all the available RAM for it. That's the reason I use iozone with test sizes twice the amount of available DRAM. Simply test it out and compare iozone -e -I -a -s 4096M -r 16384k -i 0 -i 1 iozone -e -I -a -s 4096M -r 4k -i 0 -i 1 to get an idea what's important (block size). BTW: Both tests above are rather stupid since we're interested in random I/O unless we want to use the eMMC later as data logger (only then sequential transfer speeds are interesting -- this is what most people miss, they think an SBC is a digital camera and that's why we find all these moronic 'dd' and 'hdparm' pseudo benchmarks on the net. To test random I/O too we would have to add '-i 2' to the command line. And then we can also reduce the test size from 4GB to just 100 MB (and end up with the exact iozone command line at the start of this thread).
Guest fossxplorer Posted July 21, 2016 Posted July 21, 2016 I've never used iozone, but according to http://linux.die.net/man/1/iozoneit supports DIRECT_IO: -I Use DIRECT IO if possible for all file operations. Tells the filesystem that all operations to the file are to bypass the buffer cache and go directly to disk. (not available on all platforms) I dunno what "if possible" means though as when using dd with iflag/oflag=direct it always bypasses the cache/buffer in Linux. On server i generally use 'fio' to test IOPS, and dd or hdparm to get a quick indication of the sequential read/write performance.
tkaiser Posted July 21, 2016 Author Posted July 21, 2016 On server i generally use 'fio' to test IOPS, and dd or hdparm to get a quick indication of the sequential read/write performance. But we're not talking about 'servers' here. Simply give the above two iozone calls a try, compare with dd and hdparm and see why the latter are inappropriate (again: block/record size matters, I won't repeat this any here since it's that easy to get the idea by simply trying the stuff out -- this thread here is full of examples that show how much different record/block sizes matter. People using dd don't think about this -- sometimes they use the default, that's just 512 bytes, sometimes they do copy&paste from stuff on the web and end up with 'bs=1M', both values pretty dumb to describe normal IO workload scenarios )
fossxplorer Posted July 21, 2016 Posted July 21, 2016 Fio can be used wherever you want to test the IOPS performance.Fio is especially interesting on flash based devices (SSD/eMMC/SD), although i've only tested on SSDs. And it gives you IOPS as a metric. It can give an indication of IOPS of the device given a block size the test is run with. I will give iozone a try and if i get time, also try to compile fio on Armbian.
tkaiser Posted July 21, 2016 Author Posted July 21, 2016 try to compile fio on Armbian. Why? Regarding available software Armbian is more or less the distro chosen (Wheezy, Jessie, Ubuntu Trusty or Xenial). Simply try out what you get when searching for it: apt-cache search "^fio" The packages Armbian provides are mostly u-boot, kernel (+ headers), firmware and board support packages. Simply compare with the output from: apt-get -q update && awk -F": " '/Package: / {print $2}' /var/lib/apt/lists/apt.armbian.com* | sort | uniq
Ford Prefect Posted July 29, 2016 Posted July 29, 2016 Hi On another forum I learned that using the noatime option in /etc/fstab for ext4 SD cards was a good idea. Any thoughts on that ? Basically it avoids writing access time each time something is read from the card.
Igor Posted July 30, 2016 Posted July 30, 2016 Hi On another forum I learned that using the noatime option in /etc/fstab for ext4 SD cards was a good idea. Any thoughts on that ? Basically it avoids writing access time each time something is read from the card. rw,noatime,nodiratime,errors=remount-ro,commit=600 Those are default mount options on Armbian since early days.
sysitos Posted August 2, 2016 Posted August 2, 2016 I think it is because to move data you first write it in RAM and Linux uses all the available RAM for it. My first thinking too, but f3 doesn't use cache (under linux - see homepage of f3) but writes directly. Verified by the values of the top program. 24MB/s is not that much or in other words: An indication that F3 uses rather small block sizes. Please compare with post #45 and #48 here: http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/?p=9886 Would be interesting if it's a thermal issue or not (I had the same issues on Beelink X2's eMMC way early) Checked with another board, same behavior. But now I monitored it with armbianmonitor running by side. Temperature starts at 50°C, with the high IO values. After 2GB of writing the temperature reaches 72°C and the rate drops to 7MB/s. Both stays there to the end of writing. Board was without any cooling at all. Checked now with my new heat sink (passive one, covered the CPU full, but the 4 eMMC only partial). The writing rate is now nearly constant 11 MB/s. The temperature starts at ca. 40°C (hehe, its really hot here in Germany at the moment ) and goes to approx. 52°C. And this only with a f.. simple heat sink. Why they don't deliver one mounted as standard. These are only cents. And we have with armbian already a cool system, not comparable with the original android they deliver. So I love my Odroid C2, already a nice heat sink mounted and it stays cool. So why the check with f3 and not iozone? 1. I want to verify the eMMC. And both boards are ok. 2. I want to check if there are IO drops, if the used memory get higher. Think of some Samsung SSDs, they have lousy rates if they are nearly full, or think of NVidias disaster with some 4GB Video cards, with the slow last GB. So maybe a interesting comparison, check the io rate with iozone on an empty card. Create a huge dummy file and compare it again with iozone. Btw, don't know how much space is required for iozone.
mss Posted August 19, 2016 Posted August 19, 2016 Nice review and a great work !I try to test my storage but after I run iozone and cancel it(it take too long and didn't finish) some strange things happens !My file system get locked! root@orangepipc:~# touch test touch: cannot touch ‘test’: Read-only file system root@orangepipc:~# reboot -bash: /sbin/reboot: Input/output error my board : orange pi pc my sd card: galecy bit 16Bit U1 my kernel: Linux orangepipc 3.4.112-sun8i #8 SMP PREEMPT Tue May 31 19:00:17 CEST 2016 armv7l GNU/Linux
tkaiser Posted August 19, 2016 Author Posted August 19, 2016 My file system get locked! And dmesg will tell you the reason: Filesystem corrupted due to using faulty or counterfeit SD card and kernel trying to save your FS by setting it to read-only Call dmesg and watch for ext4/corruption, then follow the checking procedure on another system as outlined in our documentation: http://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card or throw the card away. 1
Icarus Posted September 10, 2016 Posted September 10, 2016 Quick Question. What is a difference between Samsung Evo and Evo+ ? I am about to buy a 64GB version for my OrangePi, but i don't know which to choose.
Igor Posted September 11, 2016 Posted September 11, 2016 Check the numbers above. Both are O.K. and there is not much difference anyway.
rodolfo Posted September 12, 2016 Posted September 12, 2016 A simple solution : http://forum.armbian.com/index.php/topic/1925-some-storage-benchmarks-on-sbcs/#entry15314
Ludwig Jessica Posted November 19, 2016 Posted November 19, 2016 24MB/s is not that much or in other words: An indication that F3 uses rather small block sizes. Please compare with post #45 and #48 here: http://forum.android.../?p=9886 Which one is the best for maximum number of writing times?
Igor Posted November 19, 2016 Posted November 19, 2016 Which one is the best for maximum number of writing times? Hard to say, we haven't done durability tests ... BTW: I was using Samsung EVO for www / database server for about one year. No problems, but also not enough time to make any conclusions.
hojnikb Posted November 19, 2016 Posted November 19, 2016 Which one is the best for maximum number of writing times? That would be this https://www.sandisk.com/home/memory-cards/microsd-cards/high-endurance-microsd I'm guessing this must be using a better binned MLC flash. Don't know about random performance though. Is there any particular reason why you're worried about endurance ?
![m][sko](https://forum.armbian.com/uploads/n2a/n2a-180904eb9612afa23a4c3358385bd86f384613e3.avatars_letters_gd.png){kind=avatar}
Recommended Posts