Tipps zum vfat-Dateisystem unter Linux
Das vfat-Dateisystem bietet trotz der langjährigen Unterstützung unter Linux immer noch viele Fallstricke. Anhand einiger praktischen Anwendungsfälle werden diese aufgezeigt und Lösungen vorgestellt.
Anpassung der Systemzeit
Ein ganz hinterhältiges Problem lauert bei allen, deren Systemzeit auf "Europe/Berlin" gestellt ist. Unix-Dateisysteme berücksichtigen nämlich im Gegensatz zu vfat beim Anzeigen des Dateidatums sowohl Schaltsekunden in der Vergangenheit als auch die Sommerzeit. Konkret bedeutet dies im Falle vfat, dass der Zeitpunkt der letzten Änderung einer Datei, die im Januar angelegt wurde, im Juni um eine Stunde verschoben ist. Bei jeder Zeitumstellung würde rsync folglich alle Dateien neu übertragen.
Für die Neugierigen ein konkretes Beispiel:
# Auf vfat wird das Datum während der Sommerzeit mit der aktuellen # Zeitzone (Sommerzeit) ergänzt und damit um eine Stunde verfälscht. > TZ=Europe/Berlin ls -l --time-style=full-iso /myvfat/testfile -rwxrwxrwx [...] 2003-11-26 02:53:02.000000000 +0200 # Auf ext3 wird das Datum auch während der Sommerzeit korrekt angezeigt: > TZ=Europe/Berlin ls -l --time-style=full-iso /myext3/testfile -rw-rw-rw- [...] 2003-11-26 02:53:02.000000000 +0100
Da ich keine Mountoption für vfat fand, mit der man die Zeitzone bestimmen könnte, stellte ich die Systemzeit auf eine Zeitzone, die keine Sommerzeit kennt (z.B. "UTC") und stellte sicher, dass alle Benutzer die lokale Zeitzone "Europe/Berlin" eingestellt haben. Als Konsequenz werden nun allerdings auch alle Zeitstempel von syslogd die von der lokalen Zeitzone abweichende UTC-Zeitzone benutzen.
Unter Debian wäre hierfür ein Aufruf von base-config notwendig. , und bringt einen zum Ziel. Jedenfalls sollte es danach in etwa so aussehen:
> cat /etc/timezone Etc/UTC > ls -l /etc/localtime [...] /etc/localtime -> /usr/share/zoneinfo/Etc/UTC # ~/.bash_profile export TZ=Europe/Berlin
Beschränkung der Dateigröße
Unter Linux werden von vfat nur Dateien bis zwei Gigabyte Größe unterstützt. Größere Dateien können zumindest zur Sicherheitskopie in kleinere Dateien aufgeteilt auf das vfat-Dateisystem kopiert werden. Eine 5GB-cryptoloop-Datei sichere ich beispielsweise mit folgendem Befehl in 2000MB-Stücken auf die externe vfat-Festplatte:
> cd /myvfat > split -d -b 2000m /myext3/cryptfile cryptfile_backup > ls cryptfile_backup00 cryptfile_backup01 cryptfile_backup02
Im Falle eines Falles können die Datei-Stücke natürlich auch wieder zusammengefügt werden:
# Linux > cat cryptfile_backup00 cryptfile_backup01 cryptfile_backup02 > cryptfile # DOS > copy /b cryptfile_backup00 + cryptfile_backup01 + cryptfile_backup02 cryptfile
Anwendung von rsync
Auch beim Aufruf von rsync müssen die Besonderheiten von vfat berücksichtigt werden. Da vfat symbolische Links, Berechtigungen, Besitzer, Gruppen und Geräte nicht unterstützt, würde die Verwendung des Parameters -a, der die zuvor genannten Punkte berücksichtigt, (abgesehen von Fehlermeldungen) keine Auswirkungen haben. Deshalb beschränkt man sich am besten auf genau die Parameter, die man tatsächlich benötigt:
-r, --recursive Ordner rekursiv behandeln -v, --verbose übertragene Dateien anzeigen -t, --times Zeiteigenschaften erhalten -n, --dry-run Testlauf ohne Kopiervorgang --exclude zu ignorierende Dateien
-t natürlich notwendig. Und um Überraschungen zu vermeiden, empfehle ich, vor jedem rsync-Lauf den gewünschten Befehl mit der Option -n zu testen.Die letzte Hürde vor einem erfolgreichen Abgleich mit rsync ist die Zeitauflösung des vfat-Zeitstempels. Diese beträgt nämlich etwas mehr als eine Sekunde. Damit rsync nicht "auf die Sekunde genau ist", muss man eine zu tolerierende Zeitabweichung von einer Sekunde mit der Option --modify-window=1 einstellen.
Mit dem folgenden Befehl kann man somit endlich effizient die Dateien eines ext3-Dateisystems auf ein vfat-Dateisystem übertragen.
rsync -rvtn --modify-window=1 --exclude "lost+found" /myext3/* /myvfat
Probleme mit großen vfat-Dateisystemen
Das rasante Wachstum der Festplattengröße stellt die eher stiefmütterlich weiterentwickelten dosfstools und vfat-Treiber vor Probleme.
Verlorene Cluster
Unter dem Linux-Kernel 2.4.x führt eine Begrenzung des Cluster-Datentyps zum Datenverlust, sobald das vfat-Dateisystem mit etwa 130GB gefüllt ist. Im Kernel 2.6.x wurde dieses Problem wohl eher zufällig behoben, als viele Variablen konsequent mit einem neuen Typ versehen wurden. Eine ausführliche Beschreibung des Bugs, eine Testsuite und einen Patch (von Erik Andersen) findet man im Linux-Kernel Archive: http://www.ussg.iu.edu/hypermail/linux/kernel/0312.0/1036.html (Der Patch erlaubt übrigens auch Dateien mit einer Größe von bis zu vier Gigabyte.)
Wer mit einem 2.4.x-Kernel arbeitet und dessen vfat-Partition entsprechend gefüllt ist, darf sich demzufolge darauf gefasst machen, dass geschriebene Daten in neu erstellten Verzeichnissen nach dem Unmounten verloren gehen. Die betroffenen Dateien haben nach dem erneuten Mounten die Dateigröße 0 und die Cluster hängen in der Luft. Mit dosfsck kann man die unzugeordneten Cluster löschen.
Hoher Hauptspeicherbedarf bei dosfsck
Um die Dateisystemprüfung möglichst effizient durchzuführen, kopiert dosfsck beide FATs in den Hauptspeicher. Bei dem sehr großen Dateisystem auf einer 250GB-Festplatte führt die hohe Clusteranzahl schnell zu einem enormen Hauptspeicherbedarf, der meine 350MB (inlusive swap) knapp überstieg, so dass dosfsck mit einem malloc-Fehler abbrach. Roman Hodek, der dosfsck-Maintainer, schlägt vor das Programm auf mmap() umzustellen, weist jedoch gleichzeitig darauf hin, dass die Umstellung aufwändig ist. Solange dies nicht durchgeführt wird, sollte man also für ausreichend Hauptspeicher sorgen.
