Tobi’s Blog

Wenn man schon so ‘nen Schicken EEE-PC 901 geschenkt bekommt, will man den ja auch richtig einrichten. In dem Ding ist z.B. eine SSD verbaut und da sich die Schreibzyklen stark auf die Lebensdauer auswirken, dachte ich mir, kann man da doch bestimmt was machen.

Geplant war, die Teile der Platte, die häufige Schreiboperationen erdulden müssen, irgendwie zu schützen und die Änderungen gesammelt auf die Platte zu schreiben. Genau nach diesem Prinzip funktioniert unionfs. Man kann beliebig viele Quellen der Reihe nach übereinander legen und die oberste Quelle mit Schreibrechten wird eben zum Schreiben aller Änderungen benutzt, die darunter liegenden Schichten nur zum Lesen. Im vorliegenden Fall habe ich also die Teile der Platte, die geschützt werden sollten, als unterste Schicht mit Schreibschutz verwendet und oben drüber eine RAM-Disk gelegt.

Orte mit vielen Schreiboperationen

Folgende Verzeichnisse konnte ich bei Ubuntu ausmachen, die oft geschrieben werden:

/tmp

Das allgemeine, temporäre Verzeichnis. Viele Scripte legen da ihren Kram ab, aber viel Platz verbraucht es nie.

/var/tmp

Noch ein temporäres Verzeichnis. Keine Ahnung, wer da so alles rein schreibt. Ebenfalls recht klein vom Platzbedarf.

/var/log

Alle Logdateien (eigentlich) aller Prozesse. Hier wird städig rein geschrieben und gerade Desktopanwender brauchen die Infos nie

/media

Ein leeres Verzeichnis, in dem beim mounten von z.B. USB-Sticks Verzeichnisse als Einhängpunkte erstellt und später wieder entfernt werden.

/home/*/

Das Benutzerverzeichnis des aktuell angemeldeten Benutzers wird bei laufender X-Oberfläche ständig beschrieben. Da ist, neben /var/log, so ziemlich am meisten los.

/etc/mtab

In dieser Datei wird jegliches Ein- und Aushängen von Datenträgern dokumentiert.

Bei so vielen zu schützenden Verzeichnissen bedeutet das am Ende aber, dass man viele RAM-Disks anlegen muss. Ich bin mir nicht sicher, aber die Dinger wachsen dynamisch mit bis zur angegebenen Obergrenze, wenn man Daten hinein legt. Entfernt man aber Daten, glaube ich nicht, dass der Speicher wieder freigegeben wird. Zumindest nicht alles und auch nicht sofort. Also sollte es, um dieser Frage einfach aus dem Weg zu gehen, nur eine RAM-Disk geben. Außerdem ist dann die Verwaltung des verbrauchten Platzes einfacher und die Überwachung, wie viel noch frei ist, ebenfalls.

SSD-FS als Init-Script

Um die Aufgabe möglichst einfach zu erledigen, hab ich dieses ssdfs-Script erstellt, dass zur Boot-Zeit direkt nach dem mounten aller normalen Laufwerke aus /etc/mtab eine RAM-Disk erstellt und an die entsprechenden Verzeichnisse per mount –bind hängt. Auch /etc/mtab wurde per –bind an eine Datei auf der RAM-Disk gebunden. Die Verzeichnisse, deren Daten erhalten bleiben sollen, wurden per unionfs und weiteren Teilen der RAM-Disk schreibgeschützt. Die Installationsanleitung sowie ein paar Kommentare zum Verhalten und ein paar Schalter zum Debuggen etc. sind im Script selbst ganz oben enthalten. Das Script würde ich aber als Entwicklerversion ansehen und keinesfalls für den Normalbetrieb benutzen. (siehe weiter unten)

Erfolge

Insgesamt konnte ich das Dateisystem damit so schützen, dass vom Einschalten des Rechners bis zum Ausschalten nur 45 Schreiboperationen ausgeführt wurden. Und die alle in /etc/mtab (mehr dazu gleich, unter “Probleme”). Alle Änderungen an den Daten werden beim Runterfahren am Stück geschrieben und so unnötiges Schreiben verhindert.

(Schwere) Probleme

Folgende Probleme sind mir beim Entwickeln aufgefallen, die leider so gravierend sind, dass ich das Projekt erst mal verworfen habe:

Unionfs kann kein Merge

Mit unionfs kann man auf simple Weise die ursprünglichen Daten und Änderungen trennen. Das wird z.B. bei Live-CDs benutzt, um das System normal zu benutzen ohne auf die CD-ROM schreiben zu können. Aber es wurde nur GENAU DAFÜR gemacht. D.h. man kann nicht sagen “führe die Änderungen jetzt mal auf die ursprünglichen Daten aus”. Im Script habe ich einen Trick benutzt, das selber zu machen: es wird per rdiff einfach eine Daten mit allen Änderungen zwischen den ursprünglichen Daten und dem kompletten Unionfs durchgeführt. Das dauert zwar etwas länger, da alle Daten ein mal gelesen werden müssen, funktioniert aber zuverlässig.

Unionfs ist zickig

Wenn man unterhalb eines Unionfs per –bind Verzeichnisse eingehangen hat, bleibt ein umount des Unionfs einfach stehen. Man kann dann nur noch hart ausschalten und alle Daten, die noch nicht auf die Platte gesynct wurden, sind verloren. Auch kann man Unionfs-Quellen nur aushängen, nicht den Status ändern oder sie gar wieder einhängen. Das führt ebenfalls zum Absturz des Unionfs und eben wieder zum Datenverlust. Daraus ergibt sich, dass man ein Sync der Daten auf die Platte nur genau ein mal machen kann. Ein regelmäßiges Syncen, um Datenverluste zu vermeiden durch ausgehen des Rechners z.B. durch zu wenig Akkuleistung, ist nicht möglich.

/etc/mtab wird uneinheitlich verwendet

Hier waren, nach dem alles andere recht gut lief, die letzten 45 Schreiboperationen zu finden. In dem Init-Script der mtab ist extra angegeben, wenn die Datei ein Link ist, dass dieser dann korrekt behandelt wird. Das funktioniert aber gar nicht, da andere Prozesse diese Ausnahme nicht kennen und das System schon beim Starten korrumpieren. D.h. die unionfs-Laufwerke werden zwar erstellt, können aber nicht mehr gesynct werden und es gehen somit wieder Daten verloren. Per mount –bind kann man auch einzelne Dateien binden, aber auch das funktioniert hier nicht. Der df-Befehl z.B. erkennt dann überhaupt kein Laufwerk mehr, und unionfs lässt nicht schon wieder nicht unmounten… und wieder mal Datenverlust.

Umount von per –bind eingebundenen Laufwerken ist zickig

Wegen der Zickigkeit von Unionfs habe ich mehrere Laufwerke übereinander legen müssen, um z.B. das Unionfs beim Syncen mit einem Schreibschutz versehen zu können, da Unionfs bei dieser Aktion direkt abstürzt und wenn beim Syncen gleichzeitg Änderungen in der Quelle gemacht werden, bestimmt viel Datenmüll raus kommt. Bei so verschachtelten –bind Anweisungen scheint es umount irgendwann aus der Bahn zu werfen. Sporadisch wurde ein Umount verweigert, was wieder zu Datenverlust führte.

Fazit

Dieser Weg funktioniert ziemlich gut, ist aber extrem Instabil und führt zu gravierenden Datenverlusten. Zum basteln und lernen ist das gut geeignet, zu mehr aber auch nicht. Zum Vergleich: Ich habe während der Entwicklung das System ca. 200 mal neu starten müssen und ~90% der Zeit die Daten der Sitzung komplett verloren.

Ich für meinen Teil habe viel über Unionfs, die mtab und das System an sich gelernt. Das Script selber werde ich aber erst dann wieder anfassen, wenn Unionfs “etwas” stabiler geworden ist. Ansonsten richte ich mir die Umgebung gerade so ein, dass die Daten, die oft geschrieben werden, auf einer SD-Karte liegen und nicht auf der SSD, um bei Ausfällen für 10 € einfach eine neue SD-Karte zu kaufen statt einer teuren SDD. Aber dazu später mehr

PS:

Ich hab den Blog schon gute 3 Monate komplett vernachlässigt, was aber meinem Garten zuzuschreiben ist, denn im Frühling ist da einfach sehr viel zu tun. Jetzt, wo ich quasi nur auf’s Ernten warte, werd ich auch wieder mehr schreiben.