3 ms·

yep -- I've had this exact issue on zero w - corrupt FS, but not physically destroyed.

andyidsinga 8y ago
fwiw - as an addendum to that comment - I like using S3 to get my data off the zero w ASAP. ..then corrupt os etc doesn't cause too much down time and data loss.
- jws 8y ago
  If you store your data under /run (or /var/run) your district will probably put it on a RAM disk. You’ll lose it in a crash, but you won’t be writing to the SD card and provoking it to corrupt in that crash. If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes. The remote sensor systems I run lose power from time to time during the year, sometimes once a day. I’d say each time there used to be something like a 0.1% to 1% chance of corruption. Since I’ve moved to /run and a slower journal I haven’t lost an SD card[1]. Thus far it seems I have at least an order of magnitude improvement. [1] Well, I had a wind turbine tower collapse in an inaccessible location. The raspberry pi is in a lake now, but it can’t have gone far so I don’t call it “lost”. I’ll dive and recover it in the spring. That camera/sensor has spent a couple months underwater before. In fact, I’ve had three systems end up underwater for months and all the SD cards have been fine when recovered.
  - ageofwant 8y ago
    Mate, seems you have your data recovery issues licked. Perhaps now is the time to spend some time on the structural integrity of your windmills :-)
  - mrsteveman1 8y ago
    > If you store your data under /run (or /var/run) your district will probably put it on a RAM disk. You’ll lose it in a crash, but you won’t be writing to the SD card and provoking it to corrupt in that crash. > If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes. The trouble is that the OS isn't the only one writing to flash in the card, the MicroSD card controller is erasing and writing to it at random times as well even if the filesystem is read-only, with no coordination between it and the OS. As a result you can easily end up in situations where the card decided to run some housekeeping to manage the flash just milliseconds before a power cycle or a power loss, and seemingly all consumer MicroSD cards are not up to the task of keeping the data intact at the same time.
mrsteveman1 8y ago
I have probably 8-9 Zero W boards in projects at this point, running everything from cat cams, temperature sensors in various rooms, even my stereo amplifier is controlled by (but not passing audio through) a Pi Zero W. All of them now have a very specific model industrial MicroSD card in them, and none have lost or corrupted data, or refused to boot, since those cards were added. They had SanDisk ultra cards before that, and they had to be reinstalled all the time. I picked the card because it's an aMLC* model (cheap overall, $15 for 4GB, $25-28 for 8GB), which significantly improves write endurance even compared to MLC cards, and because the controller is designed to handle sudden power loss, which is where a lot of these Pi+SD problems come from; consumer MicroSD cards are generally designed for use in devices that have batteries and rarely if ever lose power suddenly, so the controller can take risks for optimization that it wouldn't otherwise want to take. They're also rated down to 0C, which I can say is definitely true as I have some operating close to that right now. This is the card: https://www.digikey.com/product-detail/en/atp-electronics-inc/AF4GUD3A-OEM/AF4GUD3A-OEM-ND/5361062 https://www.digikey.com/product-detail/en/atp-electronics-in... 4GB isn't huge in a world where 32/64GB cards are common for a similar price, but a full headless OS installation doesn't even take half of that, and there's no real use for more space most of the time. * with aMLC mode, it's still MLC flash (so cheaper than SLC), but each cell only stores a single bit rather than 2 (MLC) or 3 (TLC), so there are only 2 voltage states it needs to be able to measure, rather than 4 (MLC) or 8 (TLC). That means you lose some storage capacity (half vs MLC), but the tolerances for the voltage measured in each cell is significantly relaxed, so it remains usable long past the point where a plain MLC mode card would not be able to accurately program and measure the voltages that represent the 2-bit values of 00, 01, 10, or 11 anymore.
- StavrosK 8y ago
  You should use something else for most of these, as the Raspi is hugely overkill. Something like an ESP8266 is much better suited for sensors and things like that, and it comes with onboard storage that it uses to run its code from. Plus, it costs $3 each, is stamp-sized and has Wifi.
  - andyidsinga 8y ago

fwiw - as an addendum to that comment - I like using S3 to get my data off the zero w ASAP. ..then corrupt os etc doesn't cause too much down time and data loss.

jws 8y ago
If you store your data under /run (or /var/run) your district will probably put it on a RAM disk. You’ll lose it in a crash, but you won’t be writing to the SD card and provoking it to corrupt in that crash. If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes. The remote sensor systems I run lose power from time to time during the year, sometimes once a day. I’d say each time there used to be something like a 0.1% to 1% chance of corruption. Since I’ve moved to /run and a slower journal I haven’t lost an SD card[1]. Thus far it seems I have at least an order of magnitude improvement. [1] Well, I had a wind turbine tower collapse in an inaccessible location. The raspberry pi is in a lake now, but it can’t have gone far so I don’t call it “lost”. I’ll dive and recover it in the spring. That camera/sensor has spent a couple months underwater before. In fact, I’ve had three systems end up underwater for months and all the SD cards have been fine when recovered.
- ageofwant 8y ago
  Mate, seems you have your data recovery issues licked. Perhaps now is the time to spend some time on the structural integrity of your windmills :-)
- mrsteveman1 8y ago
  > If you store your data under /run (or /var/run) your district will probably put it on a RAM disk. You’ll lose it in a crash, but you won’t be writing to the SD card and provoking it to corrupt in that crash. > If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes. The trouble is that the OS isn't the only one writing to flash in the card, the MicroSD card controller is erasing and writing to it at random times as well even if the filesystem is read-only, with no coordination between it and the OS. As a result you can easily end up in situations where the card decided to run some housekeeping to manage the flash just milliseconds before a power cycle or a power loss, and seemingly all consumer MicroSD cards are not up to the task of keeping the data intact at the same time.

mrsteveman1 8y ago

I have probably 8-9 Zero W boards in projects at this point, running everything from cat cams, temperature sensors in various rooms, even my stereo amplifier is controlled by (but not passing audio through) a Pi Zero W. All of them now have a very specific model industrial MicroSD card in them, and none have lost or corrupted data, or refused to boot, since those cards were added. They had SanDisk ultra cards before that, and they had to be reinstalled all the time. I picked the card because it's an aMLC* model (cheap overall, $15 for 4GB, $25-28 for 8GB), which significantly improves write endurance even compared to MLC cards, and because the controller is designed to handle sudden power loss, which is where a lot of these Pi+SD problems come from; consumer MicroSD cards are generally designed for use in devices that have batteries and rarely if ever lose power suddenly, so the controller can take risks for optimization that it wouldn't otherwise want to take. They're also rated down to 0C, which I can say is definitely true as I have some operating close to that right now. This is the card: https://www.digikey.com/product-detail/en/atp-electronics-inc/AF4GUD3A-OEM/AF4GUD3A-OEM-ND/5361062 https://www.digikey.com/product-detail/en/atp-electronics-in... 4GB isn't huge in a world where 32/64GB cards are common for a similar price, but a full headless OS installation doesn't even take half of that, and there's no real use for more space most of the time. * with aMLC mode, it's still MLC flash (so cheaper than SLC), but each cell only stores a single bit rather than 2 (MLC) or 3 (TLC), so there are only 2 voltage states it needs to be able to measure, rather than 4 (MLC) or 8 (TLC). That means you lose some storage capacity (half vs MLC), but the tolerances for the voltage measured in each cell is significantly relaxed, so it remains usable long past the point where a plain MLC mode card would not be able to accurately program and measure the voltages that represent the 2-bit values of 00, 01, 10, or 11 anymore.

StavrosK 8y ago
You should use something else for most of these, as the Raspi is hugely overkill. Something like an ESP8266 is much better suited for sensors and things like that, and it comes with onboard storage that it uses to run its code from. Plus, it costs $3 each, is stamp-sized and has Wifi.
- andyidsinga 8y ago