4 ms·

It’s really not that bad if you’re using good quality cards. We’ve got a fleet of about 500 RPi based appliances in the wild, and over the course of a year will

It’s really not that bad if you’re using good quality cards. We’ve got a fleet of about 500 RPi based appliances in the wild, and over the course of a year will see 10 or so card failures - that’s a 2% failure rate. I’m pretty sure we could get it lower than that by doing some fairly minor tweaks to our base image such as sending logs to a tmpfs mount rather than disk.

alias_neo 8y ago
I have a Pi running as a WireGuard VPN into my home, to ensure it lasts, given my other SD issues, I made some tweaks to the system, tmpfs for logs and mounted read-only on boot. It's going strong and for updates I just issue a quick remount and I can change what I need.
- tjoff 8y ago
  Is that a straight forward approach? If you know of a resource about it I'd be interested. I started looking into layered filesystems for that purpose. Treat the main disk as read-only and have a writable layer in RAM that you can periodically commit to disk when desired. But it seemed to be quite cumbersome to setup.
  - alias_neo 8y ago
    It's fairly straightforward if you know what you're doing. I did it myself, I had been meaning to put a blog together about it but never got around to it, you know how these things go. I'm happy to give some pointers or find something that looks suitable when I get home, if you like. Edit: This is pretty close to what I've done with mine: https://petr.io/en/blog/2015/11/09/read-only-raspberry-pi-with-jessie/ https://petr.io/en/blog/2015/11/09/read-only-raspberry-pi-wi... When I need to update I just run the remount command (IMPORTANT: on both /boot and /), make your changes, perform your updates, clean up the apt cache, then remount read-only or just reboot.
    - kingosticks 8y ago
      I'm concerned that as density increases and TLC (and QLC) sd cards become the norm, the controllers will be forced to implement read-levelling as most SSDs already do. Once that happens, even your read-only filesystem is going to start doing writes and then we are back to square one.
      - alias_neo 8y ago
        It's not perfect, but this isn't a replacement to the tried and tested, fail-safe method of backing things up. Any decent safety solution needs to be multi-tiered; I backup my configs to Git, make a backup of the now read-only filesystem after you've set this up and put it somewhere safe, and when the worst happens, restore to a new card, or build from the backup configs. I don't keep anything critical on Pi SD cards, that's why losing so many cards has been little more than an inconvenience. For read-only filesystems, a simple copy of the card in multiple locations, on and off-site is good, for read-write, backups configs to Git, RAID arrays and off-site. If the system is time-critical, first, I would suggest not running it on a Pi, use something more reliable (I moved my home automation to a NUC because it's more reliable than the Pis were), or, use multiple Pi's in redundancy, even half a dozen Pis is cheaper than a NUC if your use-case supports distributing the load.
        kingosticks 8y ago
        It's just a big hassle when you've got a machine that you wanted to provision and forget about. I think I'll just move to booting from nfs and be done with it.

alias_neo 8y ago

I have a Pi running as a WireGuard VPN into my home, to ensure it lasts, given my other SD issues, I made some tweaks to the system, tmpfs for logs and mounted read-only on boot. It's going strong and for updates I just issue a quick remount and I can change what I need.

tjoff 8y ago
Is that a straight forward approach? If you know of a resource about it I'd be interested. I started looking into layered filesystems for that purpose. Treat the main disk as read-only and have a writable layer in RAM that you can periodically commit to disk when desired. But it seemed to be quite cumbersome to setup.
- alias_neo 8y ago
  It's fairly straightforward if you know what you're doing. I did it myself, I had been meaning to put a blog together about it but never got around to it, you know how these things go. I'm happy to give some pointers or find something that looks suitable when I get home, if you like. Edit: This is pretty close to what I've done with mine: https://petr.io/en/blog/2015/11/09/read-only-raspberry-pi-with-jessie/ https://petr.io/en/blog/2015/11/09/read-only-raspberry-pi-wi... When I need to update I just run the remount command (IMPORTANT: on both /boot and /), make your changes, perform your updates, clean up the apt cache, then remount read-only or just reboot.
  - kingosticks 8y ago
    I'm concerned that as density increases and TLC (and QLC) sd cards become the norm, the controllers will be forced to implement read-levelling as most SSDs already do. Once that happens, even your read-only filesystem is going to start doing writes and then we are back to square one.
    - alias_neo 8y ago
      It's not perfect, but this isn't a replacement to the tried and tested, fail-safe method of backing things up. Any decent safety solution needs to be multi-tiered; I backup my configs to Git, make a backup of the now read-only filesystem after you've set this up and put it somewhere safe, and when the worst happens, restore to a new card, or build from the backup configs. I don't keep anything critical on Pi SD cards, that's why losing so many cards has been little more than an inconvenience. For read-only filesystems, a simple copy of the card in multiple locations, on and off-site is good, for read-write, backups configs to Git, RAID arrays and off-site. If the system is time-critical, first, I would suggest not running it on a Pi, use something more reliable (I moved my home automation to a NUC because it's more reliable than the Pis were), or, use multiple Pi's in redundancy, even half a dozen Pis is cheaper than a NUC if your use-case supports distributing the load.
      - kingosticks 8y ago
        It's just a big hassle when you've got a machine that you wanted to provision and forget about. I think I'll just move to booting from nfs and be done with it.