On Sun, Aug 03, 2003 at 04:48:14PM +0200, Peter Wiersig wrote:
NiX - Erich Troxler wrote:
Gibt es sowas unter Linux auch?
Reiser4 wird wohl ein entsprechendes Tool mitbringen. ( http://lwn.net/Articles/41652/ - Noch nicht umsonst verfuegbar...)
Das ist zu guten Teilen etwas anderes. Reiser4 ist eine Wiederaufwärmung der Ideen zum Thema LFS (Log-Structured File System) von Margo Seltzer aus dem BSD-Team, so wie ext2 eine Wiederaufwärmung der Ideen von Margo Seltzer zum Thema ffs/ufs ist. Reiser4 ist genauso eine Verallgemeinerung von LFS, wie ext2 eine Verallgemeinerung von ffs/ufs ist. BSD LFS ist ein Dateisystem, das nicht "ein Log hat", wie ext3, Reiser3, XFS oder JFS, sondern das ein Log ist. Das bedeutet, daß alle Schreibzugriffe auf die Platte immer "hinten angehängt" werden. Wenn eine Datei überschrieben wird, überschreibt LFS nicht, sondern hängt eine Kopie der geänderten Blöcke bzw. der ganzen Datei hinten an und markiert die Kopie vorne als ungültig. Wenn die Platte voll ist, werden die als ungültig markierten und damit freien Teile der Platte vorne wieder beschrieben. Damit das funktioniert, muß ein Aufräumprozeß laufen, der die freien Teile der Platte vorne ein wenig zusammenschiebt. Außerdem muß das Dateisystem eine Idee davon haben, welche Dateien "heiß" sind, also oft geändert werden und welche Dateien "kalt" sind, also ewig liegen bis das die Zeit den Tod besiegt. LFS teilt dazu die Platte in Zonen ein (ähnlich den Block Groups in ext2 oder den Cylinder Groups in ffs) und markiert diese als kalte und heiße Zonen. Es verwendet die Platte nicht wirklich umlaufend, wo oben dargestellt, sondern es verwendet bevorzugt umlaufend die heißen Zonen. Der Aufräumprozeß fegt dann nur noch die heißen Zonen aus. LFS hatte in vielen Dingen eine bessere Performance als BSD ffs, hat aber vollkommen versagt, wenn auf dem LFS eine Datenbankdatei oder eine andere Datei lag, die datenbankartig beschrieben wurde (also in der mit fseek und write operiert wurde). Reiser4 hat ähnliche Probleme, auch wenn Hans Reiser da eine ganze Reihe von Verbesserungen vorgenommen hat. LFS hat sich nicht durchgesetzt, unter anderem weil Larry McVoy (der Bitkeeper-Typi, der damals noch bei Sun gearbeitet hat) sich den ffs-Code mal vorgenommen hat und dort nach Investition von jeder Menge Hirnschmalz ca. 50 Zeilen geändert hat. Mit dieser Änderung (die im wesentlichen kleine Teile einer Idee enthält, die eines der vielen guten Fundamente von SGI XFS sind) macht das neue FFS das LFS dann in jedem Benchmark fertig. Das ist sehr frustrierend für das Team um Margo Seltzer gewesen - FFS ist ihr Baby gewesen und weil es ihnen zu schlecht performt hat, haben sie LFS erfunden - während jemand anders genau das Problem mit 50 Zeilen aus dem Weg räumt, das Ursache für die Erfindung von LFS war... Es dokumentiert nicht nur, daß Kernelhacken zwar aussieht wie Userlandprogrammierung, aber in Wirklichkeit eine ganz andere Sportart ist. Es zeigt auch, daß Larry zwar auf der LKML ein arrogantes Arschloch ist, daß er sich das aber auch berechtigt erlauben kann, weil er um Größenordnungen genialer als der durchschnittliche Standardentwickler ist. Wer es selber lesen will: BSD84 McKusick, Karels, Leffler, ,,A Fast File System for UNIX``, ACM Transactions on Computer Systems, Vol. 2, No. 3, August 1984, Seiten 181-197 Das ist das originale FFS-Paper. Ou88 Ousterhout, Douglis, ,,Beating the I/O Bottleneck: A Case for Log Structured File Systems``, UCB/CSD 88/467, Computer Science Division (EECS), University of California, Berkeley, October 1988 Das ist die originale Idee zu LFS von Ousterhout (der, der auch TCL/Tk erfunden hat). Ou90 Ousterhout, ,,Why Aren't Operating Systems Getting Faster As Fast As Hardware?``, Proceedings of the USENIX 1990 Summer Conference, Anaheim, 1990 Ousterhout trommelt noch mal für LFS. Ro91 Rosenblum, Ousterhout, ,,The Design and Implementation of a Log-Structured File System``, Proceedings of the Symposium on Operating System Principles, Monterey, Oktober 1991 Ousterhout wieder mit "Wie geil ist unser LFS?" BSD93 Seltzer, Bostic, McKusick, Staelin, ,,An Implementation of a Log-Structured File System for UNIX``, Proceedings of the USENIX 1993 Summer Conference, San Diego, 1993 Das ist das LFS-Paper, mit einer LFS-Implementierung für BSD. Vo91 Larry McVoy, S.R. Kleiman, ,,Extent-like Performance from a UNIX File System``, Proceedings of the USENIX 1991 Winter Conference, Dallas, 1991, Seiten 33-44 Das ist Larry mit dem 50 Zeilen-Patch. Se95a Margo Seltzer, Keith A. Smith et. al., ,,File System Logging Versus Clustering: A Performance Comparison``, Proceedings of the USENIX 1995 Annual Technical Conference, Kalifornien, 1995 Margo schmollt (natürlich akademisch nur zwischen den Zeilen): "Lohnt LFS? Naja, wir haben es getuned, und es performt ganz ordentlich, aber Larry hinter den fünfzig Platten, mit den fünfzig Zeilen Patch performt noch viel besser als wir. 5 Jahre Forschung für was?" Se96 Margo Seltzer, Keith A. Smith, ,,A Comparison of FFS Disk Allocation Policies``, Proceedings of the USENIX 1996 Annual Technical Conference, San Diego, 1996 Margo macht wieder FFS... Sw96 Adam Sweeney et.al., ,,Scalability in the XFS File System``, Proceedings of the USENIX 1996 Annual Technical Conference, San Diego, Januar 1996 Die Antwort auf die Frage "Kristian, warum findest Du XFS so genial und warum will man kein anderes Dateisystem benutzen?"
Was ist am besten?
Schwer zu sagen. Es koennen bei einigen Dateioperationen die bestehenden Fragmentierungen wieder aufgeloest werden.
Insgesamt ist das Linux ext2 filesystem sehr unanfaellig gegen Fragmentierung, so das sich der Desktop-Linux-Benutzer darum keine Sorgen machen muss.
Yep. Siehe dazu den bereits zitierten SDB-Eintrag. Kristian