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 (prices have gone up a lot in 2026)
• 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, random:  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 card is quite good for phone storage. I had Sandisk Ultra 64GiB cards that were unusable to take pictures on the phone due to very long stalls. Camera app would even crash. Not with this one!

One can already see a large jump when moving from 4 to 16KiB random writes. But OS use comments are below.

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 Switch Game Storage

Bought one of these to use with my Switch but never got around to test it. Almost all cards work fine on the Switch, even a very worn and old SanDisk Ultra 64 I had around here. Nintendo has gone to great lengths to make it so.

This one will work well and is highly recommended over the official Sandisk Switch microSD cards.

As SBC OS Drive

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 eMMC like.

I have also tested this with EXT4 lately for Android installs, but the catch is it needs "stripe=64" set for 256KiB RAID like block writes.
Seems to work well enough for Android User Data partition, which is very similar to Desktop OS use. Without striping the phone is unusable.

If you feel adventurous, NILFS2 works quite well for /home partition and also on the SanDisk Ultra Extreme. It solves most of the issues of slower NAND flash, as the writes are fully log structured.
/root in NILFS2 is not recommend for Debian distros because dpkg has an install pattern that hammers the LogFS so it becomes out of space and cannot do garbage collection fast enough.

EXT4 with "stripe=64" option or NILFS2 is what I'd go for, depending on Linux distro kernel support out of the box.

Keep in mind that NILFS2 will not give you the real free space, only what has been GC already.

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. I frequently benchmark USB and microSD flash that write on a 1 to 2GiB cache and then drops below 10MB/s. Some have big issues with writing small files, slowing to a crawl.

Doesn't matter how long you write with this card, performance is constant and good.

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). 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.