Lexar microSD 633x 128GB Review

Last time I reviewed an oldie, but today we're looking at a current Lexar microSD flash card. It is part of the '633x' branded cards:

• A1 app performance class,
• U3 UHS performance class (30MB/s),
• V30 video performance class.
• Lexar specs for 128GB model is 100MB/s read and 30MB/s writes.
• 32 and 64GB models don't list write speeds above the already rated by V30/U3 class.

Lexar is, since 2017, part of the chinese company Longsys. Current microSD cards and USB drives may have no resemblance to the ones manufactured by Micron. Flash is usually from Micron but that may not always be the case.

It is available in 32 up to 512GB sizes:

• Amazon US, ~$10: link
• Amazon UK, ~£9: link

These are now generally available everywhere in the world.

Test Results

Disk size:   114GiB / 126GB
Page size:   ???
Block size:   16MiB
Open AUs (seq/random): ???
Read latency: (f3probe)

Seq. read:           92.30 MB/s
Random read 4KiB:     9.01 MB/s
Random read 16KiB:   31.57 MB/s
Random read 128KiB:  70.18 MB/s

Seq. write, cache:     N/A
Seq. write, urandom: 52.25 MB/s
Seq. write, zeros:   83.30 MB/s
Seq. write, exFAT:   73.13 MB/s (zeros written to FS)
Random write 4KiB:    6.14 MB/s
Random write 16KiB:  25.44 MB/s
Random write 128KiB: 43.37 MB/s

This drive isn't really the fastest for Raspbian or SBC use, as the 4k writes are not bad per se but the card is only rated A1, which has been mostly useful for video or picture storage.

One can already see a large jump when moving from 4 to 16KiB random writes, so EXT4 is not a good idea for this one. With the 16MiB erase block, F2FS can also use stock partitioning on this card and set segment size to '8' (16MiB size for garbage collection). BTRFS is recommended for stability, if that is required.

The card is quite fast and the reads are saturating my USB3 reader and compressible data still hits close to the rated 100MB/s.

As SBC OS Drive

My experience with using these is they are passable to OS installs, though browser profiles can cause some amount of stalls. Firefox has some tweaks and seems to issue less random writes. Definitely better and more reliable than most USB drives.

Using these as storage for Steam or for system backups has not given me many issues when paired with BTRFS. In fact, I was using this with desktop Linux and the biggest issue was really the Chrome profile, the rest was mostly doing well.

If you are feeling adventurous, NILFS2 works quite well for "/home" partition with these and SanDisk Ultra Extreme. It solves the browser profile issues, as the writes are fully log structured, unlike F2FS which has too many parallel streams open. I have seen it get corrupted with no apparent media error but also work fine.

For a simple NAS and router, these are passable but there are some delays when using BTRFS and hammering this with data. Browser profiles are definitely a problem but not as bad as SanDisk drives that stall completely doing garbage collection.

Conclusion

I was very surprised by the write speeds of such a cheap card, which I didn't really think would exceed the rated specs. So good, that I will forgive the missing 1.5GB that the card ships with...

I also cannot find indications of a write cache, common in SanDisk cards. Doesn't matter how long you write, performance recovers quickly.

I frequently benchmark USB and microSD flash that write on a 1 to 2GiB cache and then drops below 10MB/s, but this is not the case here!

I bought this to test on a Nintendo Switch, as it was cheaper than  cards from both Lexar and SanDisk. It works perfectly fine but the Switch is not very demanding on the respect.

It has also solved many problems that SanDisk cards (the Ultra series) gave me on smartphones, where it would stall the phone just taking pictures. FAT and exFAT filesystems do not play well with budget SanDisk flash.

Testing Methodology

I 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 as a package for some Linux distributions or to compile from source.

I don't publish a result of "f3probe" unless the card reports fake capacity.

Sequential writes were performed with the 'dd' command, while varying the block size. At least 1GB is written to avoid effects of pseudo-SLC caches.

IOzone is used to test random reads and writes at various sizes and with a Direct I/O option to bypass Linux cache use. Some devices will perform better with buffers but I have seldom found this to be the case. Most inevitably stall when having to do garbage collection and tend to the lower performance bound of direct I/O measurements.

Observations

exfatprogs version : 1.2.2

-------------- Dump Boot sector region --------------

Volume Length(sectors): 246915072

FAT Offset(sector offset): 16384

FAT Length(sectors): 16384

Cluster Heap Offset (sector offset): 32768

Cluster Count: 964384

Root Cluster (cluster offset): 4

Volume Serial: 0x4a210000

Sector Size Bits: 9

Sector per Cluster bits: 8

----------------- Dump Root entries -----------------

Volume entry type: 0x3

Volume label:

Volume label character count: 0

Bitmap entry type: 0x81

Bitmap start cluster: 2

Bitmap size: 120548

Upcase table entry type: 0x82

Upcase table start cluster: 3

Upcase table size: 4104

---------------- Show the statistics ----------------

Cluster size:  131072

Total Clusters: 964384

Free Clusters: 844187

Sometimes manufacturers don't really format the cards to match the underlying flash structure, so one should take this information with a grain of salt.

Interestingly, the data cluster starts at 16MiB on the partition, which leaves a 16MiB block for only the partition table and also another full one for the FAT. This seems a pretty good indication of 16MiB erase blocks, as otherwise these would be set to 4MiB as per usual SD specs.

Cluster size is set to 128KiB, which we have already posted is a size that enables pretty high throughput on all operations (and satisfies the manufacturers 45MB/s speed spec).

$ factor 126437294080

126437294080: 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 5 6029

126437294080 / 6029 = 20 MiB / 5 = 4 MiB

The factoring doesn't tell us much other than the smaller block possible is 4MiB but it can also be a further power of two bigger. Let's see if 'flashbench' confirms the 16MiB erase block size.