Just found a post that has the below hidden way down in it. [
http://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card
]

You could try running Puppy Linux which is completely ram-resident. It's
very small and blindingly fast since it runs completely in memory by
copying the storage image (on SD card in your case) into RAM at boot and
then flushing changes periodically back to storage. The frequency of this
save is user controlled including manually.

Puppy uses the layered aufs or older unionfs filesystem underneath any of
the standard Linux filesystems like ext3 or ext4. It can also reside on
FAT, or NTFS partitions.

There are at least a couple of versions of Puppy specifically designed for
the RPi, one of them created by the "Puppy Master", Barry Kauler.

For more, go to http://puppylinux.org/wikka/Puppi

On Thu, May 5, 2016 at 9:27 PM, Andrew Farnsworth <[email protected]> wrote:

> 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.

Reply via email to