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.

1. Einleitung

Viele Linux-Anwender winken ab, wenn von vfat die Rede ist. Unter Linux gibt es
ausreichend viele Dateisystem-Alternativen, die technologisch überlegen sind. Ganz zu
schweigen von der rechtlichen Seite: der Versuch von Microsoft, Lizenzen mit
einem Patent auf ein vfat-Bestandteil einzufordern, hinterlässt ein ungutes
Gefühl.

Leider ist vfat jedoch immer noch die einfachste Möglichkeit, ein unter Linux
erstelltes Dateisystem der eingeschränkten Microsoftwelt zur Verfügung zu
stellen. Mit der steigenden Popularität von mobilen Datenträgern wie
CompactFlash-Karten, USB-Sticks und externen Firewire-Festplatten wuchs die
Bedeutung des "kleinsten gemeinsamen Nenners" vfat sogar.

Die im Folgenden festgehaltenen Erfahrungen habe ich bei der Arbeit mit zwei
externen 250GB-Firewire-Festplatten (Maxtor 5000XT) gesammelt. Während die eine
Festplatte mit ext3 formatiert wurde und meine speicherhungrigen Dateien sicher
aufnahm, benutzte ich die andere unter vfat als Sicherungskopie und als Brücke
zur Windowswelt.

Ein Sonderangebot für eine USB-250GB-Festplatte bei einem Lebensmitteldiscounter
erinnerte mich kürzlich daran, dass ich eigentlich meine Erfahrungen in einem
Artikel zusammenfassen wollte. Da mit wachsender Verbreitung auch der eine oder
andere Linux-Anwender auf die selben Probleme wie ich stoßen wird, hoffe ich,
mit diesem Artikel all jenen viele Stunden Problemanalyse zu ersparen. Mein
besonderer Dank gilt Uwe Menges, der mir als Mitstreiter dieser vfat-Odyssee
beistand.

2. Abgleich von ext3- und vfat-Dateisystemen mit rsync

Die Besonderheiten des vfat-Dateisystems, die in dieser Sektion Erwähnung
finden, sind natürlich nicht nur auf die Arbeit mit rsync beschränkt. Der Bezug
zu rsync eignet sich hier jedoch sehr gut als Beispiel, bei dem sich viele der
möglichen Schwierigkeiten mit vfat zeigen.

Wer rsync noch nicht kennt, sollte wissen, dass es anhand des Zeitpunktes der
letzten Veränderung und anhand der Dateigröße entscheidet, ob eine schon im
Zielpfad existierende Datei übertragen werden muss. Unter einem Unix-Dateisystem
würde ein rsync -av quelle/* ziel gewährleisten, dass alle Dateien
des Verzeichnisses quelle identisch im Verzeichnis
ziel vorhanden sind. Bei einem sofortigen zweiten Aufruf des
Befehls würden keine Dateien mehr übertragen werden.

Damit rsync die Dateien auf zwei so unterschiedlichen Dateisystemen wie vfat und
ext3 abgleichen kann, sind einige Voraussetzungen zu schaffen, die zuerst nicht
besonders offensichtlich sind.

2.1. Erforderliche Mountoptionen

Mountet man das vfat-Dateisystem ohne Mountoptionen, so wird ein normaler
Benutzer keinen Schreibzugriff darauf haben. Weiterhin wird einem die
Sonderbehandlung der MS-DOS-Dateinamen (DATEINAM.EXT) in Form von Kurznamen ein
Bein stellen:

> mount /dev/sda1 /myvfat -t vfat
> mount | grep sda1
/dev/sda1 on /myvfat type vfat (rw)
> grep sda1 /proc/mounts
/dev/sda1 /myvfat vfat rw,nodiratime,fmask=0033,dmask=0033 0 0

> cd /myvfat
> touch ABCDEFGH
> touch ABCDEFGHI
> ls -l
-rwxr--r--     1 root root     0 Dec 31 16:05 ABCDEFGHI
-rwxr--r--     1 root root     0 Dec 31 16:05 abcdefgh
# Man beachte die Kleinschreibung  -----------^

Man kann sich vorstellen, dass rsync nicht begeistert sein wird, wenn Dateinamen
plötzlich kleingeschrieben sind, nur weil sie zufällig in das MS-DOS-Dateischema
passen. Die Dateien werden in diesem Fall bei jedem Abgleich erneut übertragen,
obwohl eigentlich keine Änderung vorliegt, da rsync sehr wohl auf
Groß-/Kleinschreibung achtet. Die hierfür verantwortliche Standard-Mountoption heißt
shortname=lower.

Um dies zu verhindern, verwendet man die Option shortname=mixed,
die den Kurznamen genau so anzeigt, wie er beim Anlegen angegeben wurde. Wer auf
korrekte Sonderzeichen beim Umwandeln der Kurznamen Wert legt, darf noch die
Option codepage=850 setzen. In der Praxis sollte das Beibehalten
der Standard-Mountoption codepage=437 jedoch keine Auswirkungen
haben, da die überwiegend verwendeten, langen Dateinamen ohnehin in Unicode
gespeichert werden. Mit der Standard-Mountoption iocharset=iso8859-1
werden diese übrigens für Linux in 8-Bit-Dateinamen gewandelt. Wer also ein
Unicode-fähiges System hat (z.B. Fedora Core) muss iocharset=utf8

explizit angeben. Ich bin leider noch nicht so weit.

Die Datei-Berechtigungen richten sich nach der umask des mount-Benutzers root
und dessen Benutzer- und Gruppen-ID. Damit man auch als berechtigter Benutzer im
Dateisystem schreiben darf, setzt man am besten mit der Option
umask=002 für Gruppenmitglieder Lese-, Schreib- und
Ausführungsrechte. Alle anderen dürfen nicht schreibend zugreifen - es schadet
nie, ein Multi-User-System als ein solches zu behandeln! Mit der
Option gid=100, gehört dann - zumindest auf meinem Debian-System -
jede Datei der Gruppe "users". Und damit von vfat nach ext3 kopierte
Dateien nicht root als Besitzer hinterlegt bekommen, stellt man mit der Option
uid=1000 auch gleich die weiteren Besitzverhältnisse auf dem
vfat-Dateisystem klar. (Auf meinem System ist 1000 die Benutzer-ID meines
Benutzers "t", der Mitglied der Gruppe "users" ist.)

> mount /dev/sda1 /myvfat -t vfat -o shortname=mixed,codepage=850,umask=002,uid=1000,gid=100
> mount | grep sda1
/dev/sda1 on /myvfat type vfat (rw,shortname=mixed,codepage=850,umask=002,uid=1000,gid=100)
> grep sda1 /proc/mounts
/dev/sda1 /myvfat vfat rw,nodiratime,uid=1000,gid=100,fmask=0002,dmask=0002,codepage=cp850,shortname=mixed 0 0

> cd /myvfat
> ls -la
-rwxrwxr-x     1 t    users    0 Dec 31 16:05 ABCDEFGH
-rwxrwxr-x     1 t    users    0 Dec 31 16:05 ABCDEFGHI

Wer diese Optionen nun in der Datei »/etc/fstab« festhalten möchte,
kann gerne noch die Optionen noauto,user hinzufügen, damit das
Dateisystem nicht automatisch beim Systemstart gemountet wird, sondern von einem
normaler Benutzer gemountet werden kann. Die Option user impliziert
aus Sicherheitsgründen die Optionen noexec,nosuid,nodev. Da in
diesem Beispiel von einem externen Datenträger für Daten ausgegangen wird,
sollte das nicht stören. Wer das Ausführen von Programmen auf dem Dateisystem
erlauben möchte, setzt zusätzlich die Option exec. Als
Optimierungsmaßnahme könnte man nun noch die Aktualisierung des letzten
Dateizugriffs mit noatime,nodiratime ausschalten, falls man diese
Information nicht benötigt. Ich persönlich benutze jedoch die Angaben, um bei
Audiodateien zum Beispiel mit find -atime -21 meine Hörgewohnheiten
der letzten drei Wochen zu untersuchen.

Die resultierende fstab-Zeile sieht folgendermaßen aus:

/dev/sda1 /myvfat vfat shortname=mixed,codepage=850,umask=002,uid=1000,gid=100,noauto,user 0 0

> mount /myvfat
> mount | grep sda1
/dev/sda1 on /myvfat type vfat (rw,noexec,nosuid,nodev,shortname=mixed,codepage=850,umask=002,uid=1000,gid=100)
> grep sda1 /proc/mounts
/dev/sda1 /myvfat vfat rw,nodiratime,nosuid,nodev,noexec,uid=1000,gid=100,fmask=0002,dmask=0002,codepage=cp850,shortname=mixed 0 0

Für Details verweise ich an dieser Stelle auf die Manpage des mount-Befehls,
speziell auf die Sektionen "Mount options for fat" und "Mount options for vfat".

2.2. 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.
»Configure timezone«, »None of the above« und
»UTC« 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

2.3. 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

Die Dateien mit einer Größe von über zwei Gigabyte müssen natürlich beim
Ausführen von rsync vom Kopiervorgang ausgenommen werden.

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

2.4. 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

Da der Zeitpunkt der letzten Dateiänderung für rsync sehr wichtig ist, ist die
Option -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

3. Probleme mit großen vfat-Dateisystemen

Das rasante Wachstum der Festplattengröße stellt die eher stiefmütterlich
weiterentwickelten dosfstools und vfat-Treiber vor Probleme.

3.1. 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.

3.2. 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.

3.3. Ausführen von dosfsck

Solange das vfat-Dateisystem gemountet ist, kann dosfsck zwar ausgeführt werden,
doch schlagen durchgeführte Reparaturen stillschweigend fehl. Deshalb sollte
zuallererst sichergestellt werden, dass es nicht gemountet ist. Im folgenden
Beispiel wird ein durch den 2.4.x-Bug unzugeordneter Cluster gefunden und
gelöscht. Der Befehl fsck.vfat ist übrigens ein symbolischer Link
auf dosfsck.

> fsck.vfat -vr /dev/sda1
dosfsck 2.10 (22 Sep 2003)
dosfsck 2.10, 22 Sep 2003, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     16384 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
  39267840 bytes per FAT (= 76695 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 78552064 (sector 153422)
   9816944 data clusters (160840810496 bytes)
63 sectors/track, 255 heads
         0 hidden sectors
 314295660 sectors total
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (641900 vs. really 641901)
1) Correct
2) Don't correct
? 1
Perform changes ? (y/n) y
/dev/sda1: 143 files, 9175043/9816944 clusters

3.4. Formatieren eines großen vfat-Dateisystems

Beim Formatieren mit »mkfs.vfat« muss die Option -F 32
angegeben werden, damit ein 32-Bit-Dateisystem erzeugt wird. Ohne diese Option
wird standardmäßig je nach Größe ein 12- oder 16-Bit-Dateisystem erzeugt bzw.
der Formatierungsvorgang bricht bei einer zu großen Partition ab. Fat16
unterstützt nämlich nur Dateisysteme bis zu zwei Gigabyte, während Fat32 bis zu
zwei Terabyte ermöglicht.

> mkfs.vfat -F 32 /dev/sda1

4. Abschluss

Die zuvor beschriebenen Probleme haben mich viel Zeit gekostet. Doch der Luxus,
dass ich meine Arbeit ausschließlich mit Freier Software verrichten kann, ist
mir mehr wert. Deshalb möchte ich all den Entwicklern der hier besprochenen
Programme herzlich danken. Wenn der Leidensdruck durch die zuvor beschriebenen
Probleme groß genug wird, finden sich vielleicht auch Freiwillige, die die
noch offene Arbeit angehen.