I will second Curt's option on the ram drive. Things were very tight on the Pi 1 and got better with the Pi 2 & 3. Especially in headless mode, it is pretty easy to allocate 256 Mb to a RAM drive or two and mount them as /tmp and /var... that all but eliminates writes to the card... now you also lose everything in them on reboot, but /tmp should that anyway and it shouldn't make that much difference with /var depending on your application.
As a point of endurance, I purchased 20 Raspberry Pi 1 back in 2014 and I have had two of them fail on hardware (not SD card) and I have had 2 others corrupt the SD card. Not too surprising as they are in an environment where they get shutdown regularly (nightly). I have contemplated running dedicated power to them rather than siphoning off the display they are attached to but it hasn't been a big enough issue yet as I keep a master SD card image around and just flash a new SD card and I'm up and running with about 4 minutes of configuration on an error. With all that, if you want to shrink the SD card image size, you can look at this article. https://www.raspberrypi.org/forums/viewtopic.php?t=19468 it talks about shrinking an SD image to fit onto a smaller SD card (both were 4GB but one was actually slightly smaller than the other) I want to do this as all my RPis have 4GB cards and I don't want to buy new ones if I don't have to when I go upgrade them to Jessie from Wheezy. Andy F On Wed, May 4, 2016 at 3:29 PM, Curt Lundgren <[email protected]> wrote: > Where SD life is concerned, we have an original Pi (700 MHz single core) > that's been running since April of 2014. No problems observed, and the run > time has been limited only be UPS life (Hint: A UPS that is issuing forth > smoke is not a good UPS.) I've had one at home running continuously with > 650+ days of uptime. I have yet to lose an SD card on a running Raspberry > Pi. In any application where I need to frequently write transient data I > use a ramdisk and only the data for the long haul gets written to SD. > > On Wed, May 4, 2016 at 2:24 PM, Bruce Martin <[email protected]> wrote: > >> If these were being used at home that is the more practical solution. >> However the projects I am working on will deploy the RPi in places like the >> top floor of a building I do not have unlimited access to and in a locked >> room that I do not have the key. Or at a tower site a couple of hours drive >> away. >> I will have the original image files made so it will just be an issue of >> re-imaging a new SD card. I just want to be sure it is a long time between >> incidents of needing to do that. >> >> Thanks for your input. >> >> Bruce >> >> On May 4, 2016, at 1:35 PM, Chris McQuistion <[email protected]> >> wrote: >> >> There are higher-end SD cards that supposedly include wear leveling. >> Those would be the cards designed for HD cameras and such. >> >> You could go that route or you could just image your system and make >> periodic backups. If the card goes bad, replace it with another $10 SD >> card, restored from backup, and call it a day. >> >> I have two Raspberry Pi systems at home and that's what I plan to do >> (just back them up and replace them when they die.) >> >> On a system that isn't do a large number of writes, an SD card should >> last for a LONG time since reads don't wear a card out. >> >> Chris >> >> On Wed, May 4, 2016 at 1:04 PM, Bruce Martin <[email protected]> wrote: >> >>> I know that dd is one of those fundamental linux commands that are used >>> occasionally but like rm need to be used carefully. >>> >>> I admit to being a rather “Appliance” operator when it come stop Linux >>> these days. I use the bistro as it is and usually install only the software >>> and updates that are part of the distribution. In the past I did download >>> the source of the latest version of software i wanted to run and compiled >>> it after tweaking the makefile and sometimes some of the code. These days I >>> do not do that very much. Lazy? Maybe but the distributions have gotten >>> better at keeping things reasonably up to date and stable and bleeding edge >>> is not my forte anymore. >>> >>> That being said I have been playing around with Raspberry Pi for the >>> last few years. I tend to buy two or three of each version as they come >>> out. I have two deployed for specific Ham radio stuff and am embarking on a >>> project to help some friends out by setting up some Broadband Speed >>> monitoring nodes. One of the shortcomings of the Raspberry Pi (RPi) is the >>> use of SD cards. Even when you are not doing a lot of writing to the card >>> the life of a card seems to be less than a year or so. >>> >>> I have read that the newer SDHC cards incorporate wear leveling much >>> like an SSD does. With this in mind I want to set up an SD card but only >>> partition it to use a third or a fourth of the disk space and leave the >>> rest of the card free and unformatted for wear leveling use. >>> >>> My experience, thus far, is that when setting up a card for the RPi the >>> distribution expands itself to use up the entire card. I want to try >>> setting things up on an 8GB car. After everything is configured I want to >>> create an image of the card and then write that image to a 16GB or 32GB >>> card. Is there a parameter in dd to limit how much of the card is used and >>> leave the rest as unformatted? Do I need to create the partitions on the >>> 32GB card and image each partition separately from the 8GB card and write >>> that image to a specific partition on the 32GB card? Is there some >>> other/better way to do this? >>> >>> I want to try to get to the point of being able to set up a RPi and let >>> it sit and run for years and not have to redo the card every year. Stories >>> of servers stuck in closets or left in a wall void during remodeling come >>> to mind. We had an APRS Igate node at Vanderbilt that ran the better part >>> of a decade without a purposeful reboot that was running on a floppy drive >>> distro that Sean Jewett and a few others worked on. I want that kind of >>> longevity in the RPi nodes I am deploying. >>> >>> Thoughts? >>> Suggestions? >>> Questions? >>> >>> Bruce >>> >>> -- >>> Bruce W. Martin, KQ4TV >>> Trustee for AA4VU >>> Vanderbilt University Amateur Radio Club >>> >> >> -- >> -- >> You received this message because you are subscribed to the Google Groups >> "NLUG" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nlug-talk?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "NLUG" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en --- You received this message because you are subscribed to the Google Groups "NLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
