Re: mount_msdosfs -> disc too big ??

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Wed, 8 Feb 2006 13:53:14 +0100 (CET)

Daniel Graupner <listen(at)danielgraupner.de> wrote:
> da ging meine erste Mail doch ohne Inhalt raus...

Manchmal geht's halt schneller als einem lieb ist. :-)

> Ich habe meine Festplatte folgendermaßen aufgeteilt:
> - Partition 1: 50GB, FAT32
> - Partition 2: 230 GB, FAT32
> - Partition 3: 10 GB, FAT32
>
> Ich habe extra FAT32 genommen um unter Windoof und FBSD
> arbeiten zu können.

NTFS wäre natürlich auch eine Möglichkeit.

> Partition 1 und 3 lassen sich problemlos einbinden, bei einem
> mountversuch "mount_msdosfs /dev/da0s5 /mnt" wird bloß die Meldung
> "disc too big" ausgegeben.
>
> Mir sind diesbezüglich keine Limits bekannt, ich brauche die
> Größe. Besteht eine Möglichkeit die Platte trotzdem zu nutzen?? Was
> ist die größtmögliche mountbare Größe bei msdosfs und warum??

Die Antwort auf die erste Frage ist einfach: 128 Gbyte.

Das »warum« ist etwas komplizierter. Bei jedem Dateisy-
stem, das von FreeBSD gemountet wird, wird erwartet, daß
jede Datei anhand einer eindeutigen Nummer identifiziert
werden kann (im Falle von UFS sind das die inode-Nummern).
Diese Nummern müssen persistent sein, d.h. für dieselbe
Datei muß immer dieselbe Nummer vorhanden sein, auch nach
einem umount und erneutem mount, da dies für NFS erforder-
lich ist, weil NFS state-less ist.

FAT hat keine solche Identifizierungsmöglichkeit, daher
»erfindet« der msdosfs-Treiber inode-Nummern, indem es
einfach alle theoretisch denkbaren Verzeichniseinträge
durchnumeriert und jeder Datei diese »virtuelle« Nummer
ihres Verzeichniseintrages zuordnet. Bei FAT ist jeder
Verzeichniseintrag 32 Bytes groß, und inode-Nummern sind
32 Bits groß -- somit ist das größte Dateisystem, das
mit diesem Mechanismus erfaßt werden kann, 32 * 2^32 Bytes
groß: 128 Gbyte. Bei größeren Dateisystemen würden die
erzeugten Nummern nicht mehr in einen 32-Bit-Wert passen.

Seit einiger Zeit gibt es einen Work-around (oder eher:
einen üblen Hack) für diese Problematik, indem Du in
Deine Kernel-config »options MSDOSFS_LARGE« reinschreibst.
Dies bewirkt, daß der msdosfs-Treiber zunächst wie gewohnt
eine virtuelle Nummer ermittelt (siehe oben). Dann wird
aus dieser 64-Bit-Nummer ein 32-Bit-Hashwert ermittelt und
im RAM gespeichert (erst beim umount wird dieser Speicher
wieder freigegeben). Dies passiert für _jede_ Datei, die
angefaßt wird. Wenn Du ein »find« oder »ls -lR« oder sonst
irgendwas Rekursives macht, passiert das also für jede
Datei, die sich im Dateisystem befindet. Und natürlich
auch jedesmal dann, wenn Du eine Datei neu anlegst, ver-
schiebst oder kopierst.

Wie man sich denken kann, hat die Sache zwei Haken:
Erstens werden pro Datei im Dateisystem 32 Bytes Kernel-
speicher (RAM) benötigt, plus Verwaltungsoverhead. Wenn
sich im Dateisystem viele Dateien befinden, kann es pas-
sieren, daß der Kernel nicht mehr genug Speicher hat, was
zu einer Panic + Reboot führt. Zweitens kann ein solches
FAT-Dateisystem nicht per NFS exportiert werden, da die
inode-Nummern nicht persistent sind: Bei einem umount geht
die Zuordnung zwischen den Dateien und den 32-Bit-Hashnum-
mern verloren.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 08 Feb 2006 - 13:54:41 CET

search this site