Reading around the web it is easy to see that SD memory and lifespan are very poorly understood. There are conflicting explanations of lifespan, there are solutions which don’t work because someone didn’t actually test them before writing up … what a mess.
So here’s the deal. SD memory (the type you put in the PI to boot up) has limited write time – SO DOES USB MEMORY.
How long the microSD in your new Raspberry Pi2 will last is anyone’s guess and depends on “disk” activity, i.e. the number of WRITES (the number of READS is irrelevant).
So how to maximise this. It would seem that you CANNOT offload the whole thing to a hard drive.. but you can have the Pi boot up from the microSD – and then do everything ELSE on the hard drive. You cannot power the hard drive off the USB on the Pi as it does not provide enough juice – so you’d need a powered USB hub. This article looks good – I only got as far as transferring files externally so don’t ask me questions on it – but this seems to be one of the better explanations for using an external file storage. https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=44177
Another way to improve the life of the SD and one that makes sense to me is a RAMDRIVE. That is instead of allowing the Pi to write constantly to log files on your Pi, have it read all log files into RAM at power up – write to the RAM and then on (intentional) power down, write back to the SD. RAM of course, you can write to forever without issue.
This kind of implies reliable power and I suggest you hunt out an uninterruptable supply – you can sometimes use those little phone charger supplies but I have found that some work, some don’t. The easy way, after backing up your Pi, is to try any one you have lying around. Plug power into the supply, plug the supply into the Pi. Watch the Pi on screen and test the keyboard or mouse. Repeatedly remove and reconnect the power to the supply – if the Pi works without any issue throughout this – then you’re probably onto a winner. I have 2 of them that work, 2 of them that don’t.
Ok, so there is a package called Ramlog which does the job of ensuring the logs are only written at power down. I followed two sets of instructions both of which failed part way through because the writer hadn’t actually tested what he was writing down, missing off a SUDO (super-user-do) command or similar. This explanation http://www.vdsar.net/limit-sd-card-writes-rasberry-pi-using-ramlog/ worked for me.
It would seem that SOME SD memory has something called “wear-levelling” in which the write use of blocks of memory in the chip are evened out so that continuously writing to one block ACTUALLY doesn’t happen as the wear is “spread” – sadly trying to find out how well this works and with which manufacturer’s chips it works – is something akin to dabbling in witchcraft. There is just so much rot out there so personally I’m not counting on it.
Oh and how do you tell if you’re reducing the number of writes – less or no flashing lights on your Pi.
I hope that helps. I’m coming to the conclusion that for long term use an external drive might be a good idea but I think I’ll wait a while until someone comes up with a package or batch file to make this nice and easy – meanwhile Ramlog seems like a good compromise.
About the only thing I did notice is that my SD usage according to WEBMIN before I installed Ramdisk was 3.5GB and after it was 7.10GFB but that’s clearly rubbish – it would be interesting to see it anyone else gets any “special effects”.
Thank you for documenting your findings here Peter, and to the commenters for their ideas! I’ll add some of mine…
I have been using the RPi for a number of years (since it was released) for various things… and before that other ARM devices like routers.
My overall impression is that the RPi is not suited for this type of “real world” hardened application where we want to get things working and then just expect them to run for many years.
I am still using RPis for DIY and prototyping things, but I think that despite the extra money, there are better more reliable SBC’s out there for this sort of project. For me, having a heating or home control system crash because of some of these things, and require an I.T. person to have physical access to the device is just not acceptable for many (I’m thinking of the many wives/girlfriends out there).
In my mind, a more reliable approach would be to have a reliable low-power server which is UPS/battery backed, has a Real-Time Clock, a SATA port for a small SSD. This way you at least have a local time source for your logging and control needs, the SSD can house boot, logging, data storage (and even file serving), and you have a real BIOS for more reliable booting. I am thinking that something like this should run around 10W and be around 300€; also Intel is making some major developments in this space so interesting options like their NUC line will continue evolving. Embedded computer manufacturers are also starting to make some very interesting gateways with I/O, serial ports, multiple LAN/WAN options, storage options… starting around 260€ and designed and tested to run 24/7 in industrial environments.
With at least one reliable “server” node on the network, having less reliable, low-power, low-cost devices become less of an issue as they can all store data directly on the other system, as well as always having fast access to the time, and even providing boot facilities like are mentioned above. They can store-and-forward from memory to a database without any flash writes.
To harden the RPi… I think it would be good if Rasbian had a Read-Only boot and root partition, like how embedded systems do it. Boot and run everything read-only, and then have some areas mounted to the writable partitions for things like file storage, configuration, etc. This is certainly less flexible, but more reliable.
Another option to avoid the cost of a more reliable computer with SSD, RTC, SATA, BIOS, UPS, is to use a remote or hosted service (like MySql on a web host provider, Time from NTP.org, etc.) however things obviously stop working if there are any problems with the Internet or servers hosting the services.
Excellent
Another option is using NFS. If you already have a NAS running (like a Synology), you can put the Pi kernel on a flashcard to boot, and have all of your filesystems on the NAS. With a setup like this no writes are done to the SD card, except when updating the kernel. Running on a NAS also means it’s easier to to snapshots, clone filesystems etc. Finally, you can share data across multible Pi’s.
another option which I've done is changed to initiatlly boot from the SD card then do everything else from a SATA SSD.
http://www.recantha.co.uk/blog/?p=12445
this article talks about the changes, I used a little SATA->USB powered adapter and a 128G Kingston SSD. Works great, less worries about killing the SD card.
Peter, I’m guessing that the main source of the writes to SD card is the collection of data points for temperatures etc. You won’t get much activity on the SD card from the control side of your home automation app.
You should take a look at the work the guys at openenergymonitor have done. The main data storage application has been optimised wrt writes for a Pi with SD card. Here is a discussion of their findings re write activity on the SD card -> https://github.com/openenergymonitor/documentation/blob/master/BuildingBlocks/TimeSeries/writeloadinvestigation.md
Maybe you should consider emoncms as the data collection hub for your applications. Fully open source with an active community.
Yes thanks for that Simon – I just read that with my Sunday morning first coffee of the day. It makes for interesting if a little frightening reading – so basically those small, efficient packages I’m sending off to MQSQL are a complete waste of time..
The problem with taking the easy route here and going external is that you then bring up a whole new game in battery backup. So as I’ve blogged elsewhere a reasonable number of the cheap phone/tablet usb battery units out there make for excellent uninterruptable power supplies for the Pi. Not so if you add a hard disk in there however. So really it would be ideal to stick with the microUSB and that by the look of it means forgetting about mysql- which is a great shame as it is SO easy to use both in Node-Red and in PHP – for example I can store data points in MYSQL and then using PHP and pulling data out of MYSQL I can produce excellent web pages of temperature even with missing data points thanks to the likes of highcharts. The openenergy information is certainly useful and informative, I wonder now that it is CLEAR there’s an issue if there are an other useful DIY blogs to show Pi/Linux beginners how to implement delayed writing etc. Ideally something that is transparent and that simply buffers up any and all writes to the SD until (a) shutdown or (b) a command (you may discover pending power loss and know your battery is only good for 5 minutes or so or (c) a defined limit of time.
Peter, I really would encourage you to take a look at emoncms. It is very easy to do all the graphs you might need and is now optimised for low writes to the SD cards.
I’ve been using it for the last couple of years to monitor my PV installation and a heat bank. It’s a very versatile system. Even if you don’t want to use the graphing etc. you could use it as the data logging part of your system and pull the data out that you need for your own graphing etc.
I would really recommend taking a couple of hours to understand how it works and fits together, it may just be what you are looking for.
Thanks for that Simon – I may well do that. I actually use Grovestreams and they are great but they don’t do MQTT and I’m really keen to get as much on MQTT as I can. I’ll take a look.
Peter, have you thought about splitting your MySQL data so that you have an immediate store in memory and then archive periodically to SD storage. Shouldn’t be that difficult to do with MySQL since the databases are just files. Admittedly, I haven’t tried it but I used to use MySQL extensively and I seem to remember you can put the db files where you want.
Alternatively something like SQLite might be better?
Berryboot
http://www.berryterminal.com/doku.php/berryboot
Makes Pi hard disk use very simple. Also I understand you can use a Pi 2 without hub to run a hard disk.
Regards
Ian
Well I have to say that Berryboot looks good – particularly the bit about running the files on networked storage… however, having spend the last 3 days getting everything installed on Debian and backed up – I think a solution that lets me change storage locations on the existing system is about all I can stomach 🙂
I would generally agree with that Ken but 3 of these are going in cupboards never to be seen again – controllng heating, lighting and much more.
Depending on what you’re doing with the Pi, I suspect that if you planned to replace the SD card yearly, you’d never hit the point of wear-related SD failure. Just a guess.
I’m also willing to bet that you will find and switch to an even better small computer within the next 2 years anyway 😉 . So your SD card may outlive your Pi.
Log file writes are an important cause of SD card wear; they tend to be quite frequent, and are subject to write amplification (flash is written in blocks that are much larger than a typical log file write). Moving them to memory can be as simple as creating a tmpfs mount for /var/log (see e.g. http://www.zdnet.com/article/raspberry-pi-extending-the-life-of-the-sd-card/).
Another alternative is to use a file system which is aware of the peculiarities of flash memory and improves both performance and wear. F2FS is well supported by Linux; I’ve personally used it for the root file system on my Raspberry Pi2 for several months without problems. (see e.g. https://www.raspberrypi.org/forums/viewtopic.php?t=47769&p=408202).
The SD standard does not mandate wear leveling. However, I understand that modern quality cards do use dynamic wear levelling, that is, if you repeatedly write the same area the flash controller will map that to different physical blocks to spread out the wear. As flash doesn’t really support TRIM, there is a small amount of overprovisioning to facilitate this. Global wear levelling, where the controller actively frees up blocks with low wear by copying their data elsewhere, works even better. I do not know whether any SD cards support this. Manufacturers for some reason tend to be quite tight-lipped about the details of their devices, perhaps because such details frequently change.