Are read only partitions safe from corruption if there's also a read/write partition on the same sd card?

Question

I want to make my operating system partitions read only, but also to have a separate small partition to occasionally write data. Will the read only OS partitions be safe if the read/write partition gets corrupted from power removal while writing? Or does the entire sd card get corrupted?

If the read only partitions are actually safe in this case, then it should be possible to detect on boot when the read/write partition has become corrupted and reformat it.

edit: This is for a special application where the RPi will never be "shut down" properly, it will just be powered off. I have experience making bootable read-only systems on the RPi and that works great, but I now need a way to keep the system safe from sd corruption while also being able to write a small amount of data sometimes.

Answer 1

This is the answer I received from user farptr on reddit, which is what I suspected was the case:

There are two kinds of corruption involved.

The first is filesystem level corruption where the kernel is holding a file change in memory still and hasn't written it out yet. If you interrupt it by losing power then your storage will be missing or have corrupted data. Your read only partition would be safe from this. Even if it was corrupted, you could repair it by reformatting the SD card.

The second is internal metadata inside the SD card itself. The SD card is actually a quantity of flash memory with a tiny controller attached to it which is basically a customised CPU. The internal controller basically runs its own internal filesystem with metadata that tracks what blocks are bad, how much each block was written to etc... Interrupting these write operations will also cause corruption and if it is bad enough then the internal controller will lock up or act strangely. The problem is that you can't wipe the internal SD card metadata so if the card may be permanently unusable. Your read only partition won't help with this.

What I'm going to do is set up the system as I originally described with the primary partitions readonly and one additional partition that is writeable, and I will write data to that partition as infrequently as possible -- only when the user makes changes to settings. My hope is that it will be extremely rare that the RPi will lose power at the exact moment that the one data file is being written.

Answer 2

Yes, if you have properly flagged the boot partition to be read-only in software then the write-protect switch on the card is irrelevant.

As for the detection and reformatting part, that would rarely happen as long as you don't just randomly lose power to the unit. Even then, Raspbian is good about keeping the write caches flushed out to disk. Only if you lose power while writing to a directory would you expect sudden loss of power to do damage to it.

The best detection method, then, would be to check for the presence of a file you know is there. If the open fails, then you could trigger a reformat. Or it might hang the machine.

In any case, be sure to use Win32DiskImager to make a .img backup so you can always just restore your SD card to a known, good state.

Answer 3

Your question is futile.

You don't even NEED to even mount the boot partition, I presume you mean /. Normal Linux writes to the filesystem all the time and won't work if it is not writable. It is possible to put these elsewhere (usually tempfs).

You need to distinguish the causes of "corruption". Most often this is just a problem, experienced by all computers which fail while writing. This is usually fixed by journalling. In rare cases powering off while the SD Card firmware is performing housekeeping can cause "corruption".

In fact, the instance of "corruption" is rare (and it never seems to happen to the experienced users).

I have had 2 SD Card problems with 5 Pi, 12 SD Cards over 4 years. One was a Card which totally failed after a few days use, and was replaced under warranty. The other was a failed update.

Mind you, I have experienced MANY problems due to operator error! This is probably cause of most reported problems. The appropriate remedy here is BACKUP.

In summary I suggest you don't bother trying to quarantine your OS. Always poweroff safely and backup regularly.