Linux op SSD: /var/log/ in tmpfs

Tegenwoordig bestaat er een prima alternatief op de klassieke harde schijf: de zogenaamde solid state drive (SSD). Voor degene die hier nog niet eerder van heeft gehoord: een SSD is eigenlijk een groot flashgeheugen zoals je dit bijvoorbeeld ook terugvindt in de kaartjes van je digitale fotocamera of je USB-stick. Een SSD is in vele opzichten beter dan harde schijf, waarvan snelheid met stip bovenaan staat. Een beetje SSD is gemiddeld 2x zo snel als een harde schijf. Uiteraard zijn er ook nadelen zoals de degradatie van de geheugencellen. Dit wil zeggen dat een geheugencel in een SSD slechts een beperkt aantal keren kan worden herschreven.

Het aantal keren dat een geheugencel herschreven kan worden is afhankelijk van het type flashgeheugen dat wordt gebruikt, maar voor de op dit moment gangbare SSD’s (bijvoorbeeld de Crucial m4 128 GB) ligt het maximum rond de 5000 keer. Dit lijkt weinig, maar ik ben zelf van mening dat dit niet meteen iets is om over in paniek te raken. Bij normaal gebruik gaat een SSD vele jaren mee en is er niks om je zorgen over te maken. Toch zijn er op internet vele tips te vinden die kunnen worden toegepast om de levensduur van je SSD te verlengen.

Omdat ik recentelijk een nieuwe hosting server (zie Traxotic Networking) heb aangeschaft met daarin een SSD, besloot ik me ook eens te verdiepen in de mogelijkheden om de (theoretische) levensduur van mijn SSD te verlengen. Op mijn server draait het Linux besturingssysteem en al snel kwam ik uit bij het het topic “SSD’s en Linux: tips en trucs” op het forum van Tweakers.net. Een mooie verzameling van zaken waar je op kunt letten wanneer je Linux vanaf een SSD gaat gebruiken.

Één van de tips is het mounten van /var/log/ in tmpfs. In lekentaal: alle logbestanden opslaan in het RAM in plaats van de SSD. In deze logbestanden wordt namelijk continu informatie weggeschreven omtrent de werking van het systeem en alle applicaties. Kortom, voor het goed kunnen beheren van mijn server zijn de logfiles onmisbaar. Er wordt dan ook behoorlijk wat informatie in de logfiles weggeschreven. Qua hoeveelheid data zijn de logbestanden niet zo spannend, maar elke toevoeging van een logregel in een logbestand resulteert in een schrijfactie. Het bijhouden van de logfiles in het RAM kan dus wel wat schrijfacties naar de SSD schelen.

Het probleem is echter dat gegevens in het RAM verdwijnen wanneer het systeem wordt uitgeschakeld of opnieuw wordt opgestart. Het risico op het uitvallen van de stroom heb ik gedekt door het gebruik van een UPS, maar het zou wel prettig zijn wanneer ik na een reboot nog steeds mijn logbestanden heb. Mijn dagelijkse backup is hierin zeker handig en voldoet prima in geval van een (uiterst zeldzame!) kernel panic, maar is onvoldoende flexibel en actueel voor een gecontroleerde reboot na bijvoorbeeld een kernel upgrade.

Goochelen met bootscripts in Debian

De basale gedachte om mijn logfiles in tmpfs veilig te stellen is vrij simpel: bij het afsluiten van het systeem kopieer ik ze van tmpfs naar de SSD (log_backup), en bij het opstarten van het systeem kopieer ik ze van de SSD naar tmpfs (log_restore). De praktijk en de wijze waarop dit werkt in Debian is echter iets complexer. Log_backup wil ik namelijk pas uitvoeren nadat alle services zijn afgesloten die gebruik maken van bestanden in /var/log/ (bijvoorbeeld bind, apache, squid, syslog, samba, en mysql), maar wel voordat de filesystems (/etc/fstab) worden geunmount. Het uitvoeren van log_restore daarentegen moet plaatsvinden nadat de filesystems zijn gemount, maar voordat alle services worden gestart. Om dit te regelen in Debian dient er even te worden gegoocheld met runlevels (het standaard runlevel in Debian is ‘2’) en dependency based boot sequencing.

Het uitvoeren van log_backup vindt plaats in runlevels 0 (halt) en 6 (reboot) en moet gebeuren vóór ‘umountfs’ en ‘umountroot’, maar pas na het afsluiten van ‘rsyslog’. Ik kies hier voor rsyslog, omdat ik heb vastgesteld dat de default shutdown dependencies in Debian zo zijn ingesteld dat rsyslog pas wordt afgesloten nadat alle services zijn afgesloten die gebruik maken van /var/log/. Ik verwacht dat dit bij andere distributies ook het geval is, omdat tijdens het afsluiten van services vaak nog informatie wordt weggeschreven in het standaard syslog.

Het uitvoeren van log_restore vindt plaats in runlevel S, maar dan wel pas na ‘$local_fs’ (dit is een virtueel initscript gedefinieerd in /etc/insserv.conf dat ervoor zorgt dat alle filesystems uit /etc/fstab gemount worden). Ik kies voor runlevel S, omdat de services die gebruik maken van /var/log/ pas worden gestart wanneer er wordt overgeschakeld naar runlevel 2.

In scriptvorm ziet dit er als volgt uit.

#!/bin/sh

### BEGIN INIT INFO
# Provides:          log_backup
# Required-Start:
# Required-Stop:     umountfs umountroot
# Default-Start:
# Default-Stop:      0 6
# X-Stop-After:      rsyslog
# Short-Description: restore logfiles in tmpfs
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin

do_start() {
        echo "Nothing to do on start. See log_restore script"
}

do_stop() {
        echo -n "LOG backup: writing logfiles (/var/log/) from RAM (tmpfs) to disk..."
        /bin/tar zpcvf /root/var_log.tar.gz /var/log/* > /dev/null
        echo "done."
}

case "$1" in
    start)
        do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        do_stop
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

#!/bin/sh

### BEGIN INIT INFO
# Provides:          log_restore
# Required-Start:    $local_fs
# Required-Stop:
# Default-Start:     S
# Default-Stop:
# Short-Description: restore logfiles in tmpfs
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin

do_start() {
        echo -n "LOG restore: restoring logfiles (/var/log/) from disk to RAM (tmpfs)..."
        /bin/tar zpxvf /root/var_log.tar.gz -C / > /dev/null
        echo "done."
}

do_stop() {
        echo "Nothing to do on stop. See log_backup script"
}

case "$1" in
    start)
        do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        do_stop
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

Zoals je ziet worden de logfiles door log_backup opgeslagen in /root/var_log.tar.gz (op de SSD) en worden ze door log_restore teruggezet naar /var/log/. Ik heb bewust voor twee aparte scripts gekozen, omdat log_backup en log_restore unieke boot/shutdown dependencies kennen die ik op mijn testmachine niet verenigd kreeg in één script.

Zorg ervoor dat deze scripts in de directory /etc/init.d/ staan en activeer ze door het uitvoeren van de commando’s: insserv -v -d log_backup en insserv -v -d log_restore. Ik heb overigens ook geprobeerd de scripts te activeren met behulp van sysv-rc-conf, maar dat werkte niet (goed).

Maak eerst een handmatige backup van /var/log/ en controleer eventueel de volgorde van de symlinks die door insserv zijn aangemaakt in de directories /etc/rcS.d/, /etc/rc0.d/, en /etc/rc6.d/ voordat je een test reboot gaat uitvoeren.

Afbeelding door Guru3D.