MicroSD Power-Loss Protection: Write Strategy, Filesystem, Card Choice

TL;DR

Power-loss survival on a MicroSD card is a system property, not a card property. Three things decide whether your device comes back with valid data: the write strategy, the filesystem and mount options, and the card’s behaviour under an interrupted program operation — in that order of how much you control them.

If you only fix one of the three, fix the write strategy. It costs a dozen lines of firmware, it works with any card, and it bounds the damage no matter what goes wrong below it.

Why a power cut corrupts a card at all

A card is NAND flash behind a controller, and a single write() passes through four stages, each with its own failure mode. The filesystem may have updated its directory entry but not the data. The page cache may still be holding dirty pages when power drops — the application got a success return, but nothing reached the medium. The controller may be halfway through programming a page. And the mapping table that makes the new location visible on the next read may not have been written yet.

The classic result is a torn write: half a metadata structure lands, half does not, and the filesystem’s own bookkeeping no longer describes the data. The second result is quieter — writes the host believed were committed, lost in a cache.

None of this is a defect. It is what the interface promises. The SD physical layer defines power-up and power-down sequences and command behaviour, but it does not guarantee that an arbitrary interrupted write is atomic (SD Association specifications, accessed 2026-10-20). That guarantee has to be built above the card.

The write strategy that bounds the damage

Never overwrite live data in place. Write to a temp file, push it to the medium, then rename it over the old one. The rename is a single metadata operation, so the file system sees either the complete old version or the complete new one.

fd = open("config.tmp", O_WRONLY | O_CREAT | O_TRUNC, 0644);
write(fd, buf, len);
fsync(fd);           // data AND metadata reach the card
close(fd);
rename("config.tmp", "config.json");   // atomic

Two details that are usually skipped, and both matter:

• fsync on the file, not just close. close() returns as soon as the kernel accepts the bytes. Only fsync waits for the card to acknowledge the program operation.
• fsync the directory after the rename if you need the rename itself to survive. On most embedded filesystems the rename is durable once the directory entry is flushed.

For data that changes continuously, use a small ring of numbered slots instead of one file. Write slot n+1, fsync, then update a single “valid slot” marker. A torn write costs you the newest record, never the file.

Filesystem and mount options

The write strategy limits the damage; the filesystem decides what a torn write does to the rest of the volume.

Filesystem	Crash behaviour	Use it when
FAT32 / exFAT	No journal. Two copies of the allocation table, but a torn write can still leave them inconsistent.	Read-mostly media, removable data, anything a PC must also read. Mount with flush so writes do not linger in cache.
ext4 (data=ordered)	Metadata journaled, data written before the metadata commits.	Linux devices with a fixed card. Keep barriers enabled.
ext4 (data=journal)	Data and metadata both journaled. Slowest, safest.	Small configuration volumes where write volume is low.
f2fs	Log-structured, designed for flash. Checkpoints bound the recovery window.	Heavily written Linux devices where FAT is too weak and ext4 wears the card.

Whichever you pick, do not disable barriers to gain write speed. Barriers are what stop the device reordering a metadata commit ahead of the data it describes — turning them off reintroduces exactly the failure you are trying to remove.

What the card contributes

Speed class is the wrong axis. U1, U3, V30 and A1/A2 describe sustained throughput and IOPS, not crash consistency. A V30 card and a cheap card behave identically in a power-cut test until the controller’s handling of an interrupted program differs.

What actually differs between cards, and what you can ask about:

• Whether the controller completes or aborts an interrupted program. A controller that finishes the page on the next power-up can turn a torn write into a clean one.
• Whether spare area is reserved for recovery. Cards that keep less spare area recover more slowly and less completely.
• Whether the card exposes a power-fail hint. Some industrial cards signal an imminent brown-out so the host can stop issuing writes.
• Lot traceability. If a batch behaves differently, you need to know which batch.

None of these appear on a consumer datasheet. If the design must survive power loss in the field, they have to be asked for explicitly and tested on your own board.

What to specify to a supplier

State the workload rather than the product: sequential or random, average and peak write rate, typical file size, expected power-removal frequency, filesystem and mount options, host interface mode, and operating temperature. Then ask for samples from the production lot, run an actual power-cut test on your board — cut at random intervals during sustained writes, reboot, verify — and only then commit to a volume.

Test protocol that has caught real problems for us, in this order:

1. Sustained write for 30 minutes, cutting power at random intervals between 0.1 s and 5 s.
2. Reboot and mount with a read-only check; record whether the volume mounts at all.
3. Compare the newest record against the host’s own log to detect silent loss, not just visible corruption.
4. Repeat at the temperature extremes you specified, because controller behaviour at -20 °C is not the behaviour at 25 °C.

A card that passes step 3 without a single silently lost record is doing what the design needs. A card that passes steps 1 and 2 but fails 3 is the most dangerous outcome, because the product looks healthy until an audit.

Where this fits your order

If you are sourcing MicroSD or TF cards for a device that can lose power, the write strategy is a firmware decision you make once, and the card specification is a purchasing decision you make per order. Send the workload description with the RFQ rather than a capacity and a speed class — it is the only way the supplier can tell you whether the card you are being quoted is appropriate, and the only way you can compare two quotes honestly.