Lifetime of SD cards running rPi/BBS?

On 2018 May 11 09:20:56, you wrote to All:

KW> I'm considering running my BBS on a Raspberry Pi, but haven't ever run KW> a BBS on solid-state media. With 24 hour random read-write access, how KW> long would an SD card be expected to last?

that depends on several factors but these days, several years is pretty standard...

on linux, one can disable what is known as "atime", one of the three time stamps, which will save a lot of write cycles...

)\/(ark

Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... I am Canadian so I think KD and Bacon are staples.

Hi,

You can mount your file system (not /boot) on a usb disk like I do on my nntp server.

On a sunny day (Fri, 11 May 2018 09:20:56 +1200) it happened snipped-for-privacy@f1.n70.z8746.fidonet.org (Kurt Weiske) wrote in :

Reading data should not be a problem, SDcard (FLESH memory) has a limited number of write cycles.

There are a number of issues here also related to the operating system, and file systems used. First thing is that SDcards have a 'smart' controller that will select a sector that has not been used before to spread the read / write cycles across the whole card. Maybe using a card that is of considerable size will on average increase lifetime. The other thing OS related is how the disk is used, if all operations are performed in memory for example. Third is that Linux caches a lot of data.

So, and modern SDcards have a huge amount of write cycles specified.

My experience is that with raspies on for several years 24/7, and some with really heavy load in the sense of at least a sector written every few minutes, have _never_ given an error (till now ;-)). Make backups, always make backups, on a regular basis, that goes for everything also harddisks. Sudden power failures can cause problems, file corruption can have other reasons, backups are essential. Especially if you are writing experimental code.

You do not say what the data-throughput is on your system, I would not expect a BBS to be that intensive unless it also stores video and files, but you could do the math and use the SDcard specs to get some idea.

Because I never had a problem, and use both old cheap cars and new expensive cards I would not worry that much about it. Just shutdown your raspi by typing 'poweroff' in a terminal and do not just unplug it, to make sure all data is written to card. Battery backup is a nice thing to have too. A 11.1 V model airplane lipo and a 5V regulator and a diode I have on some other system here, Those boards are for sale in many places too, ebay for example.

I'd say you would get a year or less. A slightly better solution is to mount the filling system on full size USB stick (not the small flush fit ones, as they are no better than SD cards), which will last 2-3 years.

If you want long term reliable storage, you need put the filing system on a proper drive. Either a USB hard drive, or an SSD with a USB to SATA adaptor. You'll probably only need a small amount of storage, and 32GB or 64GB SSDs can be picked up very cheaply.

---druck

I have several original Pi 1's which have been running 24/7 for almost

5 years. I've never had a card fail in them. The application logs quite frequently to disk and the writes are flushed. I did change the cards after around 3 years, just to be safe, and because you can't read how worn they are.

The main killer for SD cards is losing power during or shortly after writes. It's not that some filesystem writes are lost (fsck could repair a filesystem after that). The problem is that the logical to physical block mapping table which is used for wear leveling is lost or corrupted by the embedded controller, and this has the effect of shuffling a large number of blocks on the disk. This sort of corruption is not repairable by fsck, at least, not without losing substantial data from the disk, and not just data which you were recently writing.

If you do loads of writing to an SD card, you will eventually wear out the flash, but I've never had one fail that way.

--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]

Completely opposite to my experience. I haven't seen any power failures corrupt SD cards since the early firmware versions when the Pi first came out.

On the other hand we had several dozens of Pi1B's controlling smartcard MUXs. These just sit there running a very simple python server, and do no writes to the card, except for the normal Raspbian system logging (they are also powered from the host machine, and don't get shutdown gracefully when it reboots).

All these performed perfectly for 2 to 2.5 years, then one by one the SD cards failed, and had to be replaced. I took the opportunity to make up a new Raspbian Jessie lite image, with minimal logging, which should make them last a bit longer.

---druck

On a sunny day (Fri, 11 May 2018 09:20:56 +1200) it happened snipped-for-privacy@f1.n70.z8746.fidonet.org (Kurt Weiske) wrote in :

PS not sure if you are going to do more complicated things, but normally raspi's filesystems are mounted with the noatime option, to prevent writes to the card for any reads. root@raspberrypi:~# mount /dev/root on / type ext4 (rw,noatime,data=ordered)

So if you are planning to make new partitions, then mount those with the noatime option, see for example:

and man mount

There is a bit more to it, but I forgot the details.

I run several Pi 24/7

The media server is still using the original SD card after over 5 years (although the actual media files are on a 4TB usb disk)

The web server burned out the first SD card after about 4 months but the replacement is still running after almost 5 years. There are 5 websites with many SD writes from the logs, emails and weather data.

So far the 8 CCTV Pi have all been running 24/7 for over a year with about 2GB of images being written to the SD card on a daily basis. They are removed by a cron job when they are > 10 days old to let the space be re-used. I had 1 SD card fail after about a month. Its replacement and the other 7 are all working well.

So I guess sometimes you're lucky and sometimes you're not.

--
nev 
getting the wrong stick end since 1953

On Sat, 12 May 2018 08:28:31 +0100, nev young declaimed the following:

I managed to kill an SD card in a couple of days (though I didn't conclude it was dead until the third time rebuilding from NOOBS install).

Do not run the HINT benchmark (

\ ) with a swap file on the SD card! (Unfortunately, under Linux without a swap file, the out-of-memory killer kills the benchmark before it can report results; on a quad-core ARM running no-OS/bare, the end of (compiled) allocated heap is detected when malloc() reports NOMEM, and the benchmark finishes. Under Linux, it runs consuming VM/swap until a pass takes longer than some parameter.) I did buy a USB disk before killing too many more SD cards (I likely shortened the life of my BeagleBone Black eMMC too; though it was small enough that HINT didn't get too far before exiting).

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

hello mark,

ml> on linux, one can disable what is known as "atime", one of the three ml> time stamps, which will save a lot of write cycles...

can you tell me wich three time stamps there are?, and how I can switch of that "atime" one in Raspbian Linux? thanks.

Henri.

A further problem is that is is more, or less, true, depending on the actual card.

--
I would rather have questions that cannot be answered... 
...than to have answers that cannot be questioned 

Richard Feynman

On a sunny day (Fri, 11 May 2018 20:17:06 -0000 (UTC)) it happened snipped-for-privacy@cucumber.demon.co.uk (Andrew Gabriel) wrote in :

fsck will usually be able to fix the filesystem, but data that was in memory and not yet written to the card is always lost during a sudden power failure.

On 2018 May 13 12:07:00, you wrote to me:

ml>> on linux, one can disable what is known as "atime", one of the three ml>> time stamps, which will save a lot of write cycles...

HD> can you tell me wich three time stamps there are?,

of course i can...

oh wait, you actually want me to?

atime = last data access timestamp (ls -lu) mtime = last data modification timestamp (ls -l ) ctime = last file status change timestamp (ls -lc)

eg: ~/FTN/msgBase/fido/backbone/r$ stat --printf '%n\nmtime: %y\nctime: %z\natime: %x\ncrtime: %w\n' rberrypi.* rberrypi.jdt mtime: 2018-05-14 10:20:05.085918845 -0400 ctime: 2018-05-14 10:20:05.085918845 -0400 atime: 2018-05-14 10:20:05.993923284 -0400 crtime: -

rberrypi.jdx mtime: 2018-05-14 10:20:05.085918845 -0400 ctime: 2018-05-14 10:20:05.085918845 -0400 atime: 2018-05-14 10:20:05.993923284 -0400 crtime: -

rberrypi.jhr mtime: 2018-05-14 10:23:50.207019406 -0400 ctime: 2018-05-14 10:23:50.207019406 -0400 atime: 2018-05-14 10:24:05.191092660 -0400 crtime: -

rberrypi.jlr mtime: 2018-05-13 11:58:38.524440063 -0400 ctime: 2018-05-13 11:58:38.524440063 -0400 atime: 2018-05-13 11:58:39.720445910 -0400 crtime: -

HD> and how I can switch of that "atime" one in Raspbian Linux? thanks.

others have already mentioned the "noatime" switch and where it belongs...

)\/(ark

Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... Chopsticks: You don't sew with a fork so why eat with knitting needles.

Hello Henri!

13 May 18 12:07, you wrote to mark lewis:

HD> can you tell me wich three time stamps there are?, HD> and how I can switch of that "atime" one in Raspbian Linux? HD> thanks.

Try 'man mount' and 'man fstab'

Kees

mtime atime and IIRC ctime

last modfied, last accessed and when created.

You specify whether atime is to be used in a mount option, generally specified in /etc/fstab

i.e.

UUID=2be84ecd-556e-488c-a832-67c49114a06c / ext4 discard,noatime,errors=remount-ro 0 1

This is a standard mount configuration for a solid state disk linux root partion - noatime says don't update access time on files read and discard tells mount/the kernel to issue TRIM commands which help do wear levelling on SSDS.

I am not sure that the latter argumemnt applies to standard flash memory chips.

--
Socialism is the philosophy of failure, the creed of ignorance and the  
gospel of envy. 

Its inherent virtue is the equal sharing of misery. 

Winston Churchill

^^^^^^^^^^^^^^

ctime is not creation time. Read your own link l-)

--
https://www.greenend.org.uk/rjk/

You can use relatime instead of noatime, to maintain a less precise access timestamp on files, instead of none at all.

I doubt a BBS will really do enough card access to be much of a problem. It took about 6 weeks for a Pi being run as a HD time lapse camera to put an 8 GB micro SDCard into read-only mode. That took a (2 MB ish) still picture every 30 seconds (2880/day), if it wasn't dark, overlaid date/time etc information. Every 6 hours these still frames would be rendered into a previous 24 hrs timelapse video with a roughly 2 min duration. The 8 GB card could hold about 3 days worth of still images and videos before old stuff had to be deleted to make way for new. Took about the same amount of time to kill a USB stick used as the image/video store...

--
Cheers 
Dave.

Does that much actually pay attention to the atime? The only program I know about is mutt, which uses atime on your mailboxes to see if you have new email since the last time something checked. I think other email clients may do similar.

Apart from that, what needs it?

Theo