SD-Karte – Wear-Level bzw. tmpfs

Wieviele andere auch habe ich mir gedanken darüber gemacht das die SD-Karte durch häufige Schreib- / Löschzyklen zu stark verschleißt.
Da die meisten Zugriffe auf Logfiles oder temporär benötigter Dateien sind habe ich beschlossen die Verzeichnisse als Ramdrives per tmpfs zu mounten.

Folgende einstellungen sind nur für Raspbian getestet.

/etc/defaults/tmpfs

RAMLOCK=yes
RAMSHM=yes
RAMTMP=yes

TMPFS_SIZE=10%VM
RUN_SIZE=10M
LOCK_SIZE=5M
SHM_SIZE=10M
TMP_SIZE=25M

Desweiteren habe ich das „/var/log“-Verzeichnis als tmpfs per /etc/fstab gemountet.
/etc/fstab

tmpfs           /var/log        tmpfs   defaults,noatime,mode=0755,size=10M     0       0

Da es einige Programme gibt welche nicht starten wenn „ihr“ Verzeichnis mit evtl. „ihren“ Rechten nicht exestiert habe ich noch ein Init-Script geschrieben welche diese anlegt und egebenfalls die Rechte setzt:

/etc/init.d/prepare-dirs

#!/bin/bash
#
### BEGIN INIT INFO
# Provides:          prepare-dirs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Required-Start:
# Required-Stop:
# Short-Description: Create needed directories on /var/log/ for tmpfs at startup
# Description:       Create needed directories on /var/log/ for tmpfs at startup
### END INIT INFO

# needed Dirs
DIR[0]=/var/log/nginx
DIR[1]=/var/log/apache2
DIR[2]=/var/log/apt
DIR[3]=/var/log/ConsoleKit
DIR[4]=/var/log/fsck
DIR[5]=/var/log/news
DIR[6]=/var/log/ntpstats
DIR[7]=/var/log/samba
DIR[8]=/var/log/lastlog
DIR[9]=/var/log/trafficserver

case "${1:-''}" in
  start)
        typeset -i i=0 max=${#DIR[*]}
        while (( i < max ))
        do
                mkdir  ${DIR[$i]}
                chmod 755 ${DIR[$i]}
                i=i+1
        done
        # set rights
        chown trafficserver ${DIR[9]}
    ;;
  stop)
    ;;
  restart)
   ;;
  reload|force-reload)
   ;;
  status)
   ;;
  *)
   echo "Usage: $SELF start"
   exit 1
   ;;
esac

Jetzt müssen wir nur noch das Skript zum richtigen Zeitpunkt ausführen lassen:

update-rc.d prepare-dirs defaults 00

Beim nächsten start des Systems werden die Verzeichnisse /run, /run/shm, /run/lock, /tmp und /var/log als Ramdrive(tmpfs) gemountet und mit dem Script die benötigten Verzeichnisse mit den entsprechenden Rechten gesetzt.

Solltet ihr wie ich ext3 oder besser ext4 benutzen so kann man auch dort etwas am wear-leveling drehen. Es sollte wenn möglich ext4 verwendet werden da dies auch für den Betrieb auf SSDs ausgerichtet ist.

Feind eines längeren durchhalten ist das das Journal. Das Journal kann komplett abgeschaltet werden oder durch ein paar Befehlen auf das nötigste zusammengeschrumpft werden. Die Zugriffe werden auch dadurch minimiert das nicht jedesmal die Zugriffszeit geschrieben wird(Mountoptionen).

!!! Vorsicht ein paar Optionen, nobh, barrier=0 und data=writeback, sorgen zwar für etwas mehr Performance und weniger Schreibzyklen machen das System aber anfällig für Datenverlust bei nicht korrekten herunterfahren des Dateisystems(Stromausfall) !!!

Journal im „writeback“-Modus betreiben:

tune2fs -o journal_data_writeback <partition>

In der /etc/fstab folgende Mountoptionen an die einzelnen einzuhängenden Partitionen hinzufügen oder ersetzen:

defaults,noatime,nodirtime,discard,nobh,barrier=0,data=writeback,errors=remount-ro (für Journal "writeback)

 

Was die einzelnen Optionen bedeuten lest ihr hier nach: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt.

Update:

Dank eines Updates des Kernel auf Version 3.10+ in Raspbian kann man das „Flash-friendly-Filesystem“ f2fs nutzen. Dieses wurde von Samsung in die Welt gesetzt und verspricht ein besseres Wear-leveling von NAND-Speichern bzw. überhaupt ein Wear-Leveling. Hier ist es nicht in einem Subsystem wie z.b. bei jffs oder ubifs sondern direkt im Filesystem integriert.

Seit Version 1.2 exestiert auch ein fsck.f2fs. Wie immer wird das FS angelegt in dem man ein:

mkfs.f2fs -l <Label> <Device>

aufruft. Laut Benchmarks im Internet arbeitet f2fs schneller als seine Kollegen jffs und ubifs – hier soll jeder seine eigenen erfahrungen machen.

Das FS eignet sich so wunderbar für die SD-Karte, den USB-Stick oder einen integrierten NAND-Flash wie z.b. auf dem Cubieboard. Soweit es das Wear-Leveling angeht glaube ich allerdings nicht das f2fs sich auf einer SSD besser macht da hier in der Regel ein entsprechendes Wear-Level Management implementiert ist. Auch sollte man sich im klaren sein das f2fs auf journaling verzichtet – wie wichtig dies ist muss auch hier jeder für sich entscheiden.

Interessanter Artikel dazu: An f2fs teardown – LWN.