In this question over at superuser several answers report SDHC card failures in Raspberry Pi single-board computers and other embedded devices over the course of periods varying from weeks to years.

In comments to this answer to an unrelated question about the swappiness, there was speculation as to whether adjusting swappiness to favour file cache pages over anonymous pages would increase the longevity of SD cards in embedded systems that rely on SD cards as their primary storage medium. Intuitively it seems that adjusting swappinness should have some effect on writes to the SD cards, but it is difficult to tell it is difficult how much swapping contributes to the overall strain on the SD card endurance compared to other contributing factors, such as logging or temporary files.

The question is: How much does adjusting the swappiness really affect the longevity of SD cards in such systems?

Answers should be backed up by specific experiences or references. Please keep Good Subjective, Bad Subjective in mind.

1 Answer 1


The answer to this depends heavily on your use case.

I no longer own a Raspberry Pi, but the one I used to have came with 512 MB of RAM. Conveniently, my NFS server has the same amount. In addition to NFS, this server (like all my others) has an m68k cross-compiler that sees regular use via distcc. It also has an always-on GNU screen session attached to the serial port of another server. Let's have a look at vmstat:

$ vmstat | awk '{ printf "%4s %2s %2s\n", $3, $7, $8 }' | tail -n 2
swpd si so
   0  0  0

In this case, no value of swappiness is better than any other, as the system never swaps. Small, embedded systems often don't even have swap space. From Memory Management Approach for Swapless Embedded Systems, a 2005 article in Linux Journal:

The Linux kernel Out of Memory (OOM) killer is not usually invoked on desktop and server computers, because those environments contain sufficient resident memory and swap space, making the OOM condition a rare event. However, swapless embedded systems typically have little main memory and no swap space. In such systems, there is usually no need to allocate a big memory space; nevertheless, even relatively small allocations may eventually trigger the OOM killer.

In systems that take this approach, the same holds: Since there is no swap space, swappiness can have no effect on the longevity of your storage.

If you are using your Raspberry Pi more like a desktop system, perhaps running X and doing gene sequencing in Python for your biology homework (I've seen it done), then you might have something to worry about. Let's find out:

Suppose you run low on memory and your swappiness is set very high, to almost exclusively page out program memory and retain file cache. Suppose also, for concreteness, that you have a class 8 SDHC card and that it has a (fairly low) 16-kilobyte block size.

Then you can write 8 MB/s, or 512 blocks per second. Without wear-leveling, and assuming failure after 100,000 writes, this leaves you only 195 seconds, or just over three minutes, before failure. Of course, this is a worst-case scenario. With wear-leveling, the failure-time is closer to 100,000 writes times the number of unused blocks. Say you have 1 GB, or 65,536 blocks, available for wear-leveling. In this case, you get (roughly) 65,536 times this amount of time, or about 24 years of constant swapping.

Since you probably won't be constantly swapping for 24 years, this won't likely be the cause of premature flash-demise.

Something much more likely to be a problem is the logging of access times of files. Whenever a file is read, its access time is updated unless the filesystem is mounted with the noatime option. This requires one block to be written every time a file is read.

Journaling filesystems like ext3 and ext4 write extra data to an on-medium journal upon each write. Some filesystems (e.g. ext2 or FFS) do not support journaling. Using these filesystems (or turning off journaling in others) definitely improves the longevity of flash media, but reduces data reliability in case of power loss or media-removal.

I don't think that system logs will in general contribute much to the death of flash media, as the only files in my /var/log that have changed in the past month are btmp, wtmp, and lastlog.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .