3 ms·
The typical design is to have redundant system partitions that are only ever mounted read-only and exist in a separate wear-leveling domain (through GPP partiti
by stefan_ 6y ago
The typical design is to have redundant system partitions that are only ever mounted read-only and exist in a separate wear-leveling domain (through GPP partitioning). Application data is on its own partition and raw logs aren't written to flash storage at all, they go to a tmpfs in memory.
Of course you will find few Linux distributions are set up like this, even if they would benefit tremendously (see Raspberry Pi SD card corruptions..). But your throwaway Android phone probably does it.
- bostik 6y agoFunny how history repeats itself. Nokia had logbufd on their linux devices (N770/N800/...) to prevent NAND getting abused by constant writes. They realised very early on that writing logs during runtime is essential for debugging purposes but also that it would kill the internal flash in no time at all. With tmpfs backed log partition, you still need active log rotation. Logbufd was an in-memory ringbuffer that listened on the standard syslog socket, and if you spewed too much logs, you only killed your own ability to go back in time. If you fill up tmpfs before rotation gets a chance to rescue you, you will break all applications that don't handle out-of-disk-space gracefully.
- imtringued 6y ago>see Raspberry Pi SD card corruptions Those are primarily caused by transient power loss. Yes, you can use software to paper over hardware problems but why not fix the hardware first?
- stefan_ 6y agoThe whole point of these schemes is that they are meant to survive a power loss during the very moment you are flashing a system upgrade. There is no "fix" for power loss, of course - it can happen at any time.