3 ms·

The memory system could be split in two: - One is the system memory. It'll have OS, apps, necessary data. This shouldn't change frequently. Like one update a m

The memory system could be split in two: - One is the system memory. It'll have OS, apps, necessary data. This shouldn't change frequently. Like one update a month, or a few months. Should last a lifetime. - Second is the daily data memory. Logs, metrics, whatever. This would go bad more frequently, but the functioning of the car shouldn't depend on this part. If this stops working and user doesn't replace it, the rest of the car should work, except that no new logs will be generated. Or user is given the option to upload the logs straight to the cloud (is a Tesla vehicle always online?).

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 ago
  Funny 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 ago
    The 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.

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 ago
Funny 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 ago
  The 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.