This is an adequate card for someone to install in SBCs like the Raspberry Pi, as the cache deals adequately with small random writes. I would recommend this for use with Armbian, which caches '/var/log' and the browser profile.
Formatting with BTRFS is preferred for endurance and performance (with associated gotchas) but ext4 works fine. I recommend setting the 'stride' and 'stripe_width' mkfs parameters to 16 (64KiB), which shows good performance on the Open AU and sequential write tests.
Currently, you can find the more recent "A1" version of this card for less than the UHS-I version I tested:
Amazon UK - £18.49 (link)
Amazon US - $19 (link)
Test Results
Page size: 48KiB / 16 KiB (cache)
Block size: 24MiB
Open AUs (seq/random): 64+/64+
Read latency: ~0.85ms
Seq. write, cache: 19.60 MB/s
Seq. write, direct: 15.90 MB/s
Seq. write, ext4: >10.00 MB/s
Seq. write, direct: 15.90 MB/s
Seq. write, ext4: >10.00 MB/s
Random write 4KiB: 2.18 MB/s
Random write 16KiB: 6.20 MB/s
Random write 64KiB: 13.50 MB/s
Random write 512KiB: 18.20 MB/s
Testing
Testing was done on an USB 2.0 card reader, so keep that in mind. At this point in time, I'm mainly focusing on looking at card internals and random read and write capabilities. If there is interest in these low level reviews, there are plans to upgrade the test bench to a less constrained setup.
Software
We use Flashbench, developed by Arnd Bergmann which can be downloaded from a forked branch at Github. The rest are standard Linux OS tools like 'dd', unless stated.
For full capacity verification, we use the 'f3' utility developed by Digirati. It is available to download at this link or as a package from your Linux distribution. We don't publish results unless the card reports fake capacity.
Sequential writes were performed with the command below, while varying the block size. At least 1GB is written to avoid effects of SLC mode caches.
dd if=/dev/zero of=/dev/sdc bs=64k seek=100000 oflag=direct status=progress
Sequential writes were performed with the command below, while varying the block size. At least 1GB is written to avoid effects of SLC mode caches.
dd if=/dev/zero of=/dev/sdc bs=64k seek=100000 oflag=direct status=progress
Benchmarking
./flashbench /dev/sdc --open-au -b $(( 16 * 1024 )) -e $(( 4 * 1024 * 1024)) --open-au-nr=32 4MiB 19.6M/s 2MiB 18.9M/s 1MiB 19.2M/s 512KiB 18.6M/s 256KiB 17.9M/s 128KiB 16.3M/s 64KiB 14.1M/s 32KiB 10.7M/s 16KiB 6.61M/s ./flashbench /dev/sdc --open-au -b $(( 16 * 1024 )) -e $(( 4 * 1024 * 1024)) --open-au-nr=64 --random 4MiB 19.3M/s 2MiB 19M/s 1MiB 19M/s 512KiB 18.2M/s 256KiB 17.2M/s 128KiB 15.4M/s 64KiB 13.5M/s 32KiB 9.56M/s 16KiB 6.22M/s 8KiB 3.86M/s 4KiB 2.18M/s
Due to time constraints, I stopped at 32 AUs for both sequential writes and 64 for random. This is a very high number, at very decent speeds when using the page size.
This is not the first card where open AUs in sequential mode equals random. It is likely that all writes are being done in a log structured manner to the SLC cache, so there are only sequential AUs and the controller will do garbage collection to TLC flash area later.
Sequential write results:
24k - 14.50 MB/s
48k - 15.70 MB/s
64k - 15.90 MB/s
96k - 15.80 MB/s
112k - 15.70 MB/s
128k - 15.50 MB/s
No problem with regards to being 'Class 10' compliant for direct device writes, although it is between 10.xx and 12.5x MB/s when writing over a file system. BTRFS was the faster one but ext4 still managed slightly over 10.
Optimal page size seems to be at least 48KiB but it is within the margin of error. Since this matches TLC NAND, this has interesting applications for the SLC cache - which seems to have a 16KiB page - as one TLC page fits 3 SLC ones.
Read tests with 'flashbench' seem to indicate a 24MiB erase block but measurements on these controllers are very noisy and it is impossible to be sure. If it is 6MiB, it is still better to align partitions to 24MiB.