Maximising SD Card Life 24/7

I can live with that lifespan :-) I didn't want to end up having to write a new one out every 3-4 months.

Reply to
mm0fmf
Loading thread data ...

The problem with /var/log on /tmp is you have no clue as to what has gone wrong when there is a problem and you have to reboot. You can set up syslog to log to another computer, but this wont help if problems are due to network issues.

---druck

Reply to
druck

There are two extremes:-

SD card - cheap flash with basic controller aimed at storing large files on a FAT32 filing system for use with cameras and misc players. Not good for being a general purposing filing system for a computer.

SSD - good quality flash with a sophisticated controller, aimed at being a general purpose read/write filing system for a computer, to replace a hard disc. Has the best performance and long levity.

USB sticks are somewhere in between. The cheap and low profile ones are often no better than SD cards when used in a Pi. The more expensive USB

3.1 and larger bar format may have a better flash and controller which are closer in performance and long levity to a low end SSD.

My experience that an SD card when used in a very active Pi, can last as little a year, but more often 2-3. A Samsung USB 3.1 bar, is much better and I've only had one fail after 4 years. The SSDs I'm using including a couple which had previously been used in a PC haven't had any failures in over 6 years.

---druck

Reply to
druck

Space. A microSD card is very very space constrained. It typically has a stack of flash dice (eg 32 dice) bonded to a controller, that all has to fit in the micro SD form factor, with very tight thickness constraints. Additionally, the form factor limits its heat dissipation. Typically the controller doesn't have much local RAM, which is used for caching and wear levelling.

A USB device isn't limited by the microSD form factor or heat budget, so there's a lot more potential for using proper controllers sometimes with dedicated RAM chips. For example the Sandisk Extreme series (at least the ones I've looked at) contains a full SATA SSD controller, with a SATA to USB bridge chip on the front. That's a lot more to fit into the package than just slapping a simple flash controller onto a stack of NAND dice.

Theo

Reply to
Theo

This is very true, but you can always revert to using the SD card if there is a repeatable issue

--
?The ultimate result of shielding men from the effects of folly is to  
fill the world with fools.? 

Herbert Spencer
Reply to
The Natural Philosopher

So far as the Pi goes there shouldn't be any worries up to 256GB, and higher for the Pi 3 and later.

formatting link

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

Thanks!

--
Cheers, 
David 
Web: http://www.satsignal.eu
Reply to
David Taylor

There is something stange with SD cards...

I've had one machine running pretty much 24/7 for over 5 years without any problems at all. I've had several others (which haven't had heavy use or been allowed to get full) fail much more quickly than that, just a few weeks in one case. The failing cards have not all been the same brand (Samsung and Sandisk, at least), and weren't bought from Ebay!

The symptom has pretty much always been the same: the SD card becomes read only, but you don't notice -- sometimes for weeks -- because Linux just keeps any changed data cached in memory. It's only when you eventually reboot the machine that the contents of the card revert back to the last time it was working properly.

Maybe it's something I'm doing to upset them, but I don't know what!

John

Reply to
John Aldridge

Bad power would be my first guess.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

formatting link

Reply to
Ahem A Rivet's Shot

They suffer from the odd power cut, but then the good one has too. The good one's an RPi2, I guess that may be significant?

--
John
Reply to
John Aldridge

More like luck. Its no different to yanking the batteries out of a running PDA/PNA/phone:

- 95%+ of the time you get away with it because the card is either not being accessed or being read.

- however, if the Pi is writing to the SD card when the power is cut, you'll get data corruption or physical damage - just data corruption if the card was being written to, but if wear levelling was in progress when the power was cut the card can become unusable.

And yes, I have seen the card in a PNA get corrupted when a mate pulled the card out while it was still shutting down - just as I'd said 'don't to that!' to him.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Am 21.03.21 um 00:40 schrieb nev young:

Hi,

can you describe your Hardware and OS / daemon from that project?

Jan

Reply to
Jan Novak

Yes.

As at Mar 2021 they are: # PiHardware, Camera, SD

1 Pi zero W, LifeCam HD-3000, 32Gb 2 Pi zero W, LifeCam Cinema, 32Gb 3 Pi zero W, LifeCam HD-3000, 32Gb 4 Pi zero, Pi NOIR cam, 32Gb 5 Pi zero W, LifeCam HD-3000, 32Gb 6 Pi zero W, LifeCam Cinema, 32Gb 7 Pi zero W, LifeCam HD-3000, 32Gb 8 Pi zero W, Pi NOIR cam, 32Gb 9 Pi zero W, GEMBIRD 8Gb 10 Pi zero, PiHut ZeroCam 32Gb

All running headless latest Raspbian Lite GNU/Linux 10 (buster) O/S and motion 4.1.1 capture software. I run apt to update/upgrade once a month. Each camera runs a cron job to purge old images every night and a cron job rsyncs the image directories to a pi file server overnight over wifi.

Cameras 4 & 8 run using IR lights.

You may get more from

formatting link
although this needs updating. There have been changes since Dec 2019 mainly re-locating webcams and rebuilding the SD cards with Rasbian Buster (from stretch) in Aug 2020. Most of the SDs were replaced as I just burned a batch of new ones and then changed them en-masse. I bought

20 32Gb SanDisk Ultra microSDHD UHS-1 cards off Amazon.
--
Nev 
It causes me a great deal of regret and remorse 
that so many people are unable to understand what I write.
Reply to
nev young

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.