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.
How does swappiness affect the longevity of SDHC memory cards in embedded computers?
linux;embedded;swap;sd card
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 sessionattached 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 2swpd si so   0  0  0In 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 Pythonfor 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 memoryand your swappiness is set very high,to almost exclusively page out program memoryand retain file cache.Suppose also, for concreteness, that you have a class 8 SDHC cardand 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 writestimes 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 isthe logging of access times of files.Whenever a file is read, its access time is updatedunless 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 ext4write 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 lossor media-removal.I don't think that system logs will in generalcontribute much to the death of flash media,as the only files in my /var/logthat have changed in the past monthare btmp, wtmp, and lastlog.