7 ms·
I've had numerous failures on older RPi models due to SD card corruption, even in non-write intensive contexts. Not sure this is good enough when you want relia
by kehrlann 8y ago
I've had numerous failures on older RPi models due to SD card corruption, even in non-write intensive contexts. Not sure this is good enough when you want reliability...
- TickleSteve 8y agoThats a well known issue with standard distributions, and there are fairly well known ways around it... Basically, don't do continuous writing to the card, turn off atime updates,possibly even work entirely from the initrd if possible. Also, use proper industrial sd cards, these have proper wear-levelling and bad-block management unlike the consumer cards. In other words, treat it as an embedded system and tailor it to your use-case.
- anfractuosity 8y agoatime refers to timestamping of files with their access time right? That sounds interesting re. turning off atime updates, how do you do that out of interest?
- Fnoord 8y ago> how do you do that out of interest? Mount with -o noatime. The default (-o relatime) should however be good enough for most situations.
- rad_gruchalski 8y agonoatime mount option
- sgt 8y agoI've tried all these "ways around it", but SD card corruption still happens on Raspberry Pi's. We use them as dashboards around the office so having them running 24/7 really tests these devices. I've found that the only working recipe for a stable Raspberry Pi is a USB hard drive (prefer SSD but mechanical also fine), and a UPS. My simple advice is: do not try to run Raspberry Pi from SD cards in "production" under any circumstances on a large scale, as you will run into filesystem corruption and create a lot of work for yourself.
- TickleSteve 8y agoI agree, which is why in a properly designed system you would run from initrd, its a single purpose system after all. No need for any sd card access once the image has been read into RAM. The SD card is read-only in this case. Also, I wouldnt trust consumer sd cards at all, they typically lack to necessary features to store data reliably anyway.
- sgt 8y agoWould TinyCore be a good option for us? We just need to run RPi's and Chromium to display a web page.
- elcritch 8y agoNot familiar with TinyCore myself, but I’d recommend trying Nerves Kiosk if a webpage kiosk is your primary goal [1]. Getting all of the FS settings right and a tuned system like daviduum talks about is tricky IMHO. Though it should be possible with Yocto Linux or similar as well I’d imagine, especially with ‘fwup’ or similar in the loop. Nerves uses ‘fwup’ [2] to create a R/O squashfs filesystem for the core OS image which is also highly compressed. 1: https://github.com/LeToteTeam/kiosk_system_rpi3/blob/master/README.md https://github.com/LeToteTeam/kiosk_system_rpi3/blob/master/... 2: https://github.com/fhunleth/fwup https://github.com/fhunleth/fwup
- bonzini 8y agoOr just make your root file system read-only. Running off an initrd greatly limits your filesystem size.
- kingosticks 8y agoCan I ask what industrial sd cards did you try? I was going to try one of those out but I'd like to know what to avoid. Thanks.
- xeeeeeeeeeeenu 8y agoIf you want reliability, buy SLC SD cards. 'SLC' keyword is much more important than the brand. There are a few companies that make them, for example Panasonic or Swissbit.
- sorenjan 8y agoI'm pretty sure my Pi failures where due to weak power supplies. I tried running a Raspberry Pi 1 B on a 1 A power supply, and after a few months it wouldn't boot. Since then I've switched to a bigger SD card (16 GB) for better wear leveling, and a 2,5 A power supply and haven't had any issues yet.
- sgt 8y agoIt's often a combination of the power supply and the type of SD cards, but eventually you will have a failure no matter what SD card you use. I've learned this the hard way from running dozens of Pi's 24/7. Looking back, I regret the decision to use Raspberry Pi. See my comment below.