Wearout Prevention of SD card memory

[Embed]

I wonder if there are mechanisms in Raspbian that prevent too many write cycles to the SD memory card that is used for booting and applications. Due to the limited number of write cycles which typical flash memory can tolerate without being worn out, this is a must in my view.

Does anyone know about this? I am particularly interested which kind of data is written frequently by the system. I am basically thinking of swap partition and system logs.
Swapping
I think there should be an option not to use swap memory at all, which should now be possible with the new 512kByte RAM of the Raspberry Pi.
Log Files
The second would then be to prevent frequent write access through log files. Here I am thinking of several possibilities:
- Configure/Modify log file managers such that they keep new lines in RAM until the buffer is full (should be 100kBytes or more) or a certain time span is over (1 hour or so)
- Set up a file system with a large write cache and configure a write back time of one hour or so
- Set up a RAM disk and direct logs to that path -> this would mean no persistent logging
- Direct logs to a console -> this would mean no persistent logging

Has anybody performed one of the suggested means? What is exactly to be undertaken (scripts, config files, re-compilation of kernel etc.?
Is there any other issue besides hardware life time that would prevent a Raspberry PI with Raspbian to run 20years without maintenance actions (replace SD card, delete files that become too big, etc.)?

[Narf03]

Good question, I wanted to know too, I'm running MySQL server in the Pi and almost writing and removing data into/from it every second, wanted to know how long the SD card can survive, taking into consideration of the wear leveling.

And btw my Pi is 500x more memory than yours. =p

[Nr90]

I think the swappiness is set very low to prevent high sd wear.

If your RPi needs to do a very high amount of read/writes you might want to consider putting the root filesystem on a USB HDD

[hojnikb]

Just dont bother with this. Sd cards can last from 1k rewrites when tlc flash is used and up to 10k when older gen mlc flash is used. Also wear levelling spreads the writes across the flash so if you physically write to just one block it wont get exhasted after 1k-10k rewrites...
Before your sd card dies you will most probobly replace your rpi or something else will break first..

BUT if you do want to "extend" the life of sd card, then use ext2 (or wait for F2FS to be supported by rpi kernel), use noatime att. in fstab, make a small tmfs in ram to move log files and other junk, so its not actually written to sd.
Also it really helps if you have as big memory card as possible. Bigger cards should in theory last more time than smaller ones...

[cnt]

...Also wear levelling spreads the writes across the flash so if you physically write to just one block ...

Who says his SD card does wear leveling? SD cards were originally intended for things like photos and movies where large files are written once and then deleted once some time later. There is nothing in the SD card spec that requires wear leveling. EXT also is not "flash aware" meaning it makes no attempt to do any wear leveling. I have heard stories that /some/ SD card markers do wear leveling but aside from a spec sheet for a particular SanDisk brand card I've never seen a card that has wear leveling listed as a feature.

The annoying thing is that SD cards also don't report faults (they have a very crude interface) so you'll only find out its bad if you get visible data corruption or an unstable OS.

[hojnikb]

Every brand name sd card (e.g not a cheap chineese knock-off) has somekind of wearlevelling, even if its not in SD spec.
But if wear levelling is a concern, using flash is a bad idea anyway

[diggmc]

Why not use tmpfs to create a small ram drive and put /var/log on it.

http://www.fewt.com/2010/07/move-your-l ... m.html?m=1

Has detailed instructions on how to do it

[mard0]

adding discard en noatime to the mount options in /etc/fstab reduces some disk writes. Also you can mount some directories that have high disk writes in ram with tmpfs. The logs will be deleted at shutdown though. Here is my current /etc/fstab:

Code: Select all

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/RootFS-Root /               ext4    noatime,discard,errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=89A5-8C32  /boot/efi       vfat    defaults        0       1
/dev/mapper/HomeFS-Home /home           ext4    noatime,discard,defaults        0       2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/log/apt tmpfs defaults,noatime 0 0
tmpfs /var/cache/apt/archives tmpfs defaults,noexec,nosuid,nodev,mode=0755 0 0

[thekeywordgeek]

I came here to post a similar question, then saw this thread.

My application, language processing, calls for a relatively unstressed MySQL database and a huge tree of many tens of thousands of small (a few k) data files. I do not want to use a traditional HDD if I can possibly avoid it. Heat, noise, power consumption etc. the Pi's advantage for me is 24/7 computing at only a few watts and a HDD would negate that.

My plan was to put both MySQL db and data file tree on a USB flash disk, and to eventually set up rsync or similar mirroring that disk to a cloud service.

I don't think I have the problem of continuous write-delete cycles as mostly once I've processed some data it stays as it is. But I am writing a huge number of tiny files, and reading them near-continuously.

So I guess I'd better ask, if there are any Flash gurus able to answer:

Do read cycles contribute to Flash wear?

Is Flash wear exacerbated by sheer numbers of files?

What is the effect on wear leveling algorithms of declining free space on a disk?

It's funny, I feel as though this is the sort of stuff I should already know, but the truth is that despite having responsibility for Linux and UNIX servers for quite a few years the hardware itself has always been someone else's problem in a data centre somewhere.

[RaTTuS]

Do read cycles contribute to Flash wear?

No

Is Flash wear exacerbated by sheer numbers of files?

no

What is the effect on wear leveling algorithms of declining free space on a disk?

none if they are correct

if you are writing lots of small files ...
it may be better to tempfs them and then use a Rsync to the SD card every hour or so .. Depending...

get a couple of SD card backups and run one until destruction and see if you need to worry ...?

[thekeywordgeek]

Sounds as though I have little to worry about then

[cnt]

What is the effect on wear leveling algorithms of declining free space on a disk?

none if they are correct

This is not quite true. Suppose you have 10 blocks and all 10 are free. Then you write a block and delete it N times. In this case a good wear leveler would write to each block the same number of times (eg block 1 then delete then block 2 delete etc) and you end up with each block being written to N/10 times. Now suppose 9 of 10 blocks are filled with unchanging data (eg the kernel), then a sequence of N block sized writes and deletes has to work one of two ways:

1) Rewrite that same block over and over again (that flash cell will die FAST)
2) Move one of the used blocks, then write the new data to the location previously held by the moved block.

In case 1, 9 of 10 blocks are written once and 1 of 10 blocks is written N times. In case 2 each block gets on average 2*N/10 writes. In this case a write of one block has been /amplified/ into a two block write. (see https://en.wikipedia.org/wiki/Write_amplification for more detail)

The bottom line is that /if/ wear leveling is happening, then the more full the disk, the worse write amplification gets. (of course w/o wear leveling the situation is even worse but there is no write amplification)

I'm still not convinced that wear leveling really happens on all SD cards. I've only seen ONE white paper from sandisk and a lot of forum hearsay saying that it happens. SD cards were originally intended for use in things like cameras where large files get sequentially written and the whole thing is erased occasionally (even one erase a day and a poor durability of 1000 cycles is almost 3 years of life). I think the problem is that people confuse SSDs, which certainly all have wear leveling with flash cards, which are MUCH simpler and may or may not wear level.

I think the best solution is to make a third partition of your flash card and use a file system that guarantees wear leveling (eg yaffs jffs2 etc see: https://en.wikipedia.org/wiki/Flash_file_system) and put log files (that you care about) and other frequently modified things there.

[John42]

I just checked a Kingston brochure:

"Wear-Leveling Technology: Kingston Flash storage devices incorporate controllers utilizing advanced wearleveling technology, which distributes the number of P/E cycles (program/erase) across the Flash memory evenly. Wear-leveling thus extends the useful life of a Flash memory card (for details, please see Kingston Flash Cell Endurance section, next)."

"There are several types of Flash storage devices that are available from Kingston:
- USB Flash Drive (DataTraveler®)
- Secure Digital Cards (SD, SDHC, SDXC, microSD, microSDHC)
- CompactFlash® Cards
- eMMC
- SSD"

Also:
http://electronics.stackexchange.com/qu ... controller

[cnt]

Interesting. maybe wear leveling is more common than I thought. Maybe the best thing to do is shop around for cards that explicitly say they wear level.

[Molski]

I finally got my two Pis in the mail yesterday! I got one setup yesterday, and I was surprised to see the distributions I was going to put on both use raw ext4. My other older embedded systems that run on compact flash, boot a read only filesystem and memory filesystems much like a live CD. But with one of my Pis, I want to do a lot of I/O on my SD with little worry.

You would not think it would be difficult to make an ext2 /boot partition, and a flash friendly file system for the root file system. It sounds cool to have a block level driver that would allow any filesystem to run on top of, but it seems SanDisk has acquired all of these projects? But it seems there are filesystems out there made for NAND flash. I'm not sure how stable YAFFS2 is, but LogFS has been in the kernel for a while it seems. I know with me being new to Linux on ARM, and flash file systems, I have a lot of research to do on this yet...

I've searched all the Raspian forums, and this is pretty much it here anyway. Has anyone done any work on things like using LogFS for a root filesystem on the Pi?

[hojnikb]

Why bother with LogFS, if you have F2FS, which is meant exactly for flash cards and other block based flash devices..

[Molski]

I said, "things like LogFS as a root filesystem." Like I said, I only just started looking into this. LogFS seemed to be around the longest with the most support. Samsung introduced F2FS only 2 months ago.

Either way, I'd be happy with any of them as a root filesystem.

[Bergschreck]

Wikipedia has a good description how wear leveling works.
USB flash drives (and I assume SD cards also) use dynamic wear leveling. This means, every time a block is rewritten, it is mapped to a different physical block of unallocated blocks.
But what, if you filled your filesystem up to 100% and then delete 50% of your files? How does the SD card know what blocks are free now? They are only marked as free in the directory of the filesystem, there is no way to mark them physically as deleted. The SD card cannot know about filesystems.

So I doubt that dynamic wear leveling really works in practice.

Is it possible to put the raspbian root filesystem on jffs2?

[jojopi]

But what, if you filled your filesystem up to 100% and then delete 50% of your files? How does the SD card know what blocks are free now? They are only marked as free in the directory of the filesystem, there is no way to mark them physically as deleted. The SD card cannot know about filesystems.

The number of user-accessible blocks reported by an SD card always seems to be at least 7% less than the total size of the flash chip. That is too much overhead to be explained by block mapping, bad blocks, and controller firmware. So I think the card is wear-levelling over a larger area than it presents, and is therefore never 100% full.

There has been discussion in other threads of whether discard/fstrim/erase are able to notify the card when blocks are no longer needed, and whether the cards can do anything with that information, which I do not think is entirely conclusive.

Anyway, although SD cards may not be particularly good at wear levelling, they are intended for use with conventional filesystems like FAT. (Unlike the obsolete SmartMedia and xD-Picture cards, and raw flash, which do require special filesystems.)

If you want your cards to last longer, write to them less. Use an external HDD/SSD or network file system if you need heavy I/O. It is not even that worn-out cards has been a commonly reported problem. Building a custom kernel and distribution with a non-standard filesystem to protect a $10 card that will be worth nothing in two years anyway, seems out of proportion.

[Bergschreck]

What about creating a second partition for data that is often written (for example /var/log) and formatting this with a filesystem that is good for flash drives? I think UDF should be a good choice, because UDF is optimized for DVD-RW and DVD-RAM which have only a limited number of write cycles.

[Un4Seen]

For users who are kind of new to Linux, could you supply some steps for following your suggestion? I mean, how to create a UDF partition and how to move /var/log to it? Also, what other parts of the system are good candidates for moving it to such a partition (what other directories have frequent read/write operations)? Also, couldn't /var/log be moved to a memory partition? If yes, how can that be achieved? I personally don't care if the logs get deleted after a reboot/shutdown.

Thanks!

[Bergschreck]

For creating a UDF filesystem you need to install the package "udftools". Then you can create the filesystem with "mkudffs" command.

Add the mount to /etc/fstab. You can use symlinks or "mount -o bind" to redirect directories to the new partition.

[Un4Seen]

Thank you!
What size do you recommend for such a partition? My /var/log is currently 52 megabaytes, but I have no idea how large it can grow...

[Bergschreck]

Sorry, I don't know. I just begin researching on this topic.

[Un4Seen]

OK, thank you for the information anyway

I'm wondering, maybe there is a way to switch logging completely off... The memory partition might not be the best solution because the RPI has little memory.