Dateisystem bei FreeBSD

[Gondrom]

Ist das FreeBSD Standard-Dateisystem empfehlenswert? Bisher habe ich auf Linuxbasis immer ReiserFS eingesetzt. Ist das FreeBSD UFS ebenfalls ein "Journaling File System" oder ist es mit Veralteten Dateisystemen wie FAT oder ext2 vergleichbar ??

MfG Gondi

[Uncle Meat]

Hallo,







das FFS (manchmal auch UFS genannt), das FreeBSD verwendet, ist


kein Journaling Dateisystem. Es ist aber auch keineswegs veraltet, da



es "Soft Updates" verwendet. Soft Updates sind ein anderer, neuerer,



eleganterer technischer Ansatz, um das gleiche Ziel zu erreichen,



das auch Journaling Dateisysteme anstreben, naemlich die Integritaet



des Dateisystems sicherzustellen und trotzdem hohe Performance zu



erreichen.



Vor einiger Zeit hat Joerg Wunsch (langjaehriges Mitglied des


FreeBSD Core-Teams) in de.comp.os.unix.bsd auf eine aehnliche

Frage recht ausfuehrlich geantwortet und ich zitiere das hier mal,



weil ich es sicher nicht so gut erklaeren koennte:







"Die Idee der Softupdates ist



(vereinfacht gesagt): es gibt zwei klassische Herangehensweisen, wie



man die Metadaten des Dateisystems (also Updates in die i-node



Bereiche oder in Verzeichnisse) auf die Platte zurückschreibt. Das



historisch völlig normale Verhalten waren synchrone Updates der



Metadaten, d. h. wenn eine Änderung an einem Verzeichnis nötig war,



wurde anschließend gewartet, bis diese Änderung zurückgeschrieben



worden ist. Die eigentlichen Datei/daten/ wurden natürlich sehr wohl



im buffer cache zwischengespeichert und asynchron irgendwann



zurückgeschrieben. Der Vorteil dieser Implementierung ist, daß sie



sehr sicher funktioniert. Wenn mitten in einem Update ein Ausfall



erfolgt, haben die Metadaten immer einen konsistenten Zustand. Eine



Datei ist entweder komplett angelegt oder gar nicht. Wenn die



Datenblöcke zur Datei den Weg aus dem buffer cache noch nicht auf die



Platte gefunden haben, dann kann das fsck dies feststellen und den



Zustand reparieren (Dateilänge wird dann auf 0 gesetzt). Außerdem ist



die Implementierung einfach und überschaubar. Nachteil ist, daß



Änderungen der Metadaten sehr langsam vor sich gehen. Ein rm -r



beispielsweise faßt alle Dateien eines Verzeichnisses der Reihe nach



an, aber jede dieser Änderungen am Verzeichnis (Löschen einer Datei)



wird einzeln synchron auf die Platte geschrieben. Gleiches beim



Auswickeln großer Hierarchien (tar -x).







Zweiter Fall sind asynchrone metadata Updates. Das ist z. B. der



Standard bei Linux/ext2fs oder die Variante -o async für *BSD ufs.



Man schickt die Updates der Metadaten einfach auch noch über den



buffer cache, sie werden also zwischen die Updates der normalen Daten



mit reingeschoben. Vorteil ist, daß man nun nicht mehr auf jeden



Update warten muß, geht also viel schneller. Auch hier ist die



Implementierung sehr einfach und wenig anfällig für Bugs. Nachteil



ist, daß keinerlei Konsistenz des Dateisystems mehr gesichert ist.



Wenn mitten in einer Operation, die viele Metadaten anfaßt (rm -r oder



tar -x) ein Ausfall erfolgt (Stromausfall, Reset-Taster), dann



herrscht anschließend Chaos auf dem Dateisystem. Niemand kann genau



sagen, was denn geschrieben worden ist und was nicht; die Datenblöcke



einer Datei können schon auf der Platte stehen, obwohl es die Updates



der i-node Tabelle oder des zugehörigen Verzeichnisses noch nicht



geschafft haben. Man kann praktisch kein fsck mehr implementieren,



das dieses Chaos wieder beräumen kann (da die dazu nötigen



Informationen schlicht auf der Platte fehlen).







Der historische Ausweg aus dem Chaos war ein `dirty region logging'.



Man schreibt die Metadaten-Updates zwar synchron, aber nur in eine



logging area. Von da aus werden sie dann asynchron auf ihre



eigentlichen Bereiche verteilt. Da die logging area ein kleines



zusammenhängendes Stückchen ist, hat man bei massiven Operationen auf



Metadaten keine allzugroßen Wege der Schreibköpfe der Platte



zurückzulegen, so daß alles ein ganzes Stück schneller geht, als bei



klassischen synchronen Updates. Die Komplexität der Implementierung



hält sich auch in Grenzen, damit die Anfälligkeit gegenüber Bugs. Als



Nachteil ergibt sich, daß Metadaten zweimal auf die Platte geschrieben



werden müssen (einmal logging region, einmal an die richtige Stelle),



so daß das Filesystem im Falle regulärer Arbeit (also keine gehäuften



Metadatenoperationen) eine ,,Pessimisierung'' des Falls der synchronen



Updates ist, es wird alles langsamer. Dafür hat man als Vorteil, daß



im Falle des Crashes der konsistente Zustand dadurch erzielbar ist,



daß die angefangenen Operationen aus dem dirty region log entweder zu



Ende ausgeführt werden oder komplett verworfen -- es geht schneller,



als ein volles fsck.







Der Ausweg von Kirk McKusick (dem Schöpfer von Berkeley FFS) nun waren



Softupdates: die notwendigen Updates der Metadaten werden im Speicher



gehalten und dann sortiert auf die Platte geschrieben (`ordered



metadata updates'). Dadurch hat man den Effekt, daß im Falle massiver



Metadaten-Operationen die nächste Operation den vorhergehenden, noch



nicht auf die Platte geschriebenen Update im Speicher ,,einholt''.



Alle Operationen auf einem Verzeichnis werden also in der Regel noch



im Speicher abgewickelt, bevor der Update überhaupt auf die Platte



geschrieben wird. (Die dazugehörigen Datenblöcke werden natürlich



auch so sortiert, daß sie nicht vor ihren Metadaten auf der Platte



sind.) Im Crashfall nun hat man ein implizites `log rewind': alle



Operationen, die noch nicht den Weg auf die Platte gefunden haben,



sehen danach so aus, als hätten sie nie stattgefunden. Man hat also



den konsistenten Zustand von ,,ein wenig früher'' garantiert. Laut



Kirk McKusick ist dabei vom Algorithmus her garantiert, daß alle



tatsächlich benutzten Ressourcen auch in den entsprechenden Bitmaps



bzw. i-node Tabellen als belegt markiert sind. Es kann lediglich



vorkommen, daß Ressourcen noch als belegt markiert waren, die gar



nicht mehr tatsächlich belegt sind. Nur um diesen Zustand zu



bereinigen, ist jetzt noch ein fsck nötig. Dieses fsck darf man aus



diesem Grunde auch ignorieren (mount -f), man hält dann eben noch



Ressourcen alloziert, die eigentlich frei sind und sollte dafür später



noch ein fsck nachholen. Das ist die ganze Idee dann des background



fsck: am Anfang wird lediglich ein Snapshot des Filesystems gemacht um



später einen Aufsetzpunkt für das fsck zu haben. Das kann dann später



im Hintergrund laufen und gibt danach die ggf. nicht mehr benötigten



Ressourcen frei.







Der Vorteil ist, daß die Metadaten-Operationen beinahe so schnell



laufen wie im asynchronen Fall (also durchaus auch schneller als beim



`journalling', das ja die Metadaten immer zweimal schreiben muß; daher



reagieren die Leute hier in der Gruppe immer etwas säuerlich, wenn



jemand nach JFS schreit und Softupdates als ,,nicht relevant'' abtun



will). Als Nachteil stehen dem die Komplexität des Codes und ein



erhöhter Speicherverbrauch entgegen. Außerdem muß man sich an paar



Eigenheiten gewöhnen, wie die Tatsache, daß nach einem Absturz ein



etwas älterer Stand auf der Platte ist (also z. B. statt der leeren



aber bereits angelegten Datei keine Spur der entsprechenden Datei mehr



zu sehen ist) sowie daß der Platz nach rm -r nicht sofort als wieder



verfügbar markiert werden kann sondern erst dann, wenn der Update dann



auch auf die Platte vermittelt worden ist."







Mehr Informationen (auf eher akademischem Niveau)zum Thema

Soft Updates und zum Vergleich Soft Updates/Journaling findest

du hier:





http://www.mckusick.com/softdep/index.html











Gruss







Thomas