SD cards are the literal worst.

they've expanded to be the size of small hard drives, and devices like the rpi keep using them as boot media, but they:

- use garbage tier low endurance flash cells internally
- have little to no overprovisioning for wear
- perform only the most basic wear levelling
- have no protocol level integrity checking
- have few internal error correction features, if any
- decay comparatively quickly without patrol scrubs
- do not perform patrol scrubs
- cannot do PLP

I've been mad about this pretty much forever. Don't use SD cards for stuff where there's literally any other option.

something I've been thinking about a lot is engineering panic signals into embedded stuff.

put a rail supervisor on the incoming supply, and leave enough capacitance on the low side of your buck(-boost) reg to keep the device running for a few milliseconds when the power is pulled. treat the supervisor IC's PG output as a panic signal and have it trigger an IO interrupt on your MCU/SoC which tells the filesystem code to ensure integrity, flush, and halt IO.

@gsuberland Yep this is something I've started to design into my architecture, prototyping on the trigger crossbar and then scaling to a next-generation system with more capabilities on my next project.

Luckily there's not a whole lot to worry about in terms of data integrity because MicroKVS is a) seldom written and b) designed to not corrupt data if interrupted at any point.

At some point I need to build a board where I can test that assumption: have one MCU that controls power to another and the target is just constantly booting up, doing KVS reads and writes, and being randomly reset/power cycled.

And see if I can make it break.