Skip to main content
Commonmark migration
Source Link

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.

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.

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.

Source Link
Paul Slocum
  • 231
  • 2
  • 10

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.