Rausschreiben

Irgendwann muss ein Dateisystem auch erfahren, ob bestimmte Daten sicher auf der Platte gelandet sind, ob zum Beispiel das Journal oder jeder wichtige Block eines COW-B-Tree wirklich geschrieben sind oder sich eventuell noch im Disk-Cache befinden. Um zu testen, ob alle Daten geschrieben sind oder noch welche im Cache liegen, gibt es ein SATA-Kommando, aber dummerweise nur so generell. Spezifische Fragen nach dem Verbleib einzelner Blocks funktionieren mit SATA nicht. Jedenfalls kanns man nicht mit jeder Hardware überprüfen, ob einzelne Blocks schon geschrieben sind oder nicht. Wenn man bedenkt, dass die Disk-Caches zwischen 16 und 32 MByte groß sind und die Schreibrate bis zu 100 MByte/s beträgt, mag das nicht viel erscheinen. Wenn aber die zu schreibenden Daten auf der Disk verteilt sind oder noch weitere Caches ins Spiel kommen, kann das zu einer ziemlichen Verzögerung führen.

Die Verwendung von SATA-Kommandos zum Leeren des Caches heißt in Fachkreisen auch Disk Barriers [1] . Vor Kernel-Version 2.6.31 funktionieren sie in den meisten Distributionen nicht mit dem Disk Mapper, je nachdem welche Patches der Distributor selbst eingebaut hat. Ext4, Btrfs und XFS verwenden standardmäßig solche Barriers. Auch wenn Metadaten-intensive Operationen mit Barriers etwas langsamer werden, machen sie das Dateisystem etwas widerständiger gegen Stromausfälle und Crashes. Der Administrator kann sie kann sie auf Wunsch auch abschalten, wer aber keinen Batterie-gepufferten Server hat, wird hoffentlich nun Barriers eingeschaltet lassen. Der Autor dieses Artikels hat in Tests herausgefunden, das die Aktivierung von Barriers Metadaten-Operationen bis zum Faktor 10 verlangsamen können.

Speicher

Es gibt mehrere Arten, die Datenbytes einer Datei auf einer Festplatte zu speichern. Jede Methode sollte aber garantieren, dass das Dateisystem sie später möglichst schnell wiederfindet. Mit Block-Mapping teilt man die Platte in Blöcke fixer Größe auf und speichert zu jeder Datei eine Liste von Blocknummern ab, damit alle Bestandteile der Datei wieder auffindbar sind.

Bei kleinen Dateien kann die Blockliste zusammen mit den I-Node-Informationen gespeichert sein. Bei größeren Dateien wird nur ein Zeiger auf einen weiteren Block gespeichert, der wiederum die Blockliste enthält. Bei noch größeren Dateien kommt noch eine weitere Ebene dazu und so weiter. Das kann natürlich irgendwann dazu führen, dass die vielen Blocks über die Platte verstreut liegen. Ein schlaues Dateisystem wird beim Schreiben darauf achten, möglichst viele zusammenhängende Blöcke zu speichern.

Extent-basierte Ansätze speichern dagegen kontinuierliche Folgen von Bytes. In einer idealen Welt würde ein 10 GByte große Video-Datei in einer einzigen Folge von Bytes gespeichert und somit nur sehr wenig Metadaten erfordern, um sie zu lokalisieren. Ebenso könnte man diese Daten vom Start bis zum Ende ohne Seek lesen. Mit Extents und minimaler Fragmentierung eines Dateisystems sollte sich eine Datei viel schneller löschen lassen als mit blockbasierter Speicherung. In einem Artikel von Christoph Hellwig [2] ist von einem Benchmark zu lesen, bei dem die Löschung einer 60 GByte großen Datei mit Ext3 etwa 50 Sekunden dauert, bei Ext4 nur zwei Sekunden und bei XFS sogar nur 0,04 Sekunden. Die letzten beiden Dateisysteme verwenden Extents, was nahe legt, dass sie gut geeignet sind, wenn man häufig große Dateien anlegt und wieder löscht, zum Beispiel bei der Videobearbeitung.

Die Achillesferse Extent-basierter Dateisysteme liegt in der Fragmentierung. Ein pathologischer Fall ist beispielsweise P2P-Filesharing, bei dem im Laufe eines längeren Zeitraums kleine Stücke größerer Dateien ankommen, die sich an ganz unterschiedlichen Stellen des gesamten Files befinden. Das kann dann zu hunderten kleiner Extents führen, die diese kleinen Teile beinhalten.

Um Fragmentierung zu verhindern, kann ein Dateisystem das Schreiben der Daten erst einmal aufschieben, das heißt dann Delayed Allocation. Wenn zum Beispiel ein Programm eine neue Datei anlegt und immer wieder, mit Pausen dazwischen, Blöcke von 64 KByte reinschreibt, bevor es sie schließt. Wenn das Dateisystem die Daten bis zum Schluss im Cache hält, weiß es schließlich, wie groß die Datei ist und kann entsprechend Platz reservieren. Das verhindert nicht nur Fragmentierung, sondern führt auch dazu, dass es alle Daten in einem Rutsch schreiben kann. Ein Dateisystem mit blockbasierter Speicherung würde eine Gruppe freier Blocks suchen und die Daten so schreiben, dass beim zukünftigen Lesen möglichst wenig Seek-Operationen nötig sind. Bibliotheks-Funktionen wie »fallocate()« erlauben es Programmen, das Dateisystem vorab darüber zu informieren, wie groß eine Datei werden wird, aber nicht alle Programme machen davon Gebrauch.

Trotz Delayed Allocation und Fallocate ist Fragmentierung bei Extent-basierten Dateisystemen unvermeidlich. Wenn zum Beispiel das Dateisystem sehr voll ist und das Schreiben einer großen Datei ansteht, wir es wohl oder übel die Datei in mehrere Extents aufteilen müssen. Deshalb haben viele Dateisysteme Mechanismen eingebaut, die während des Betriebs ("online") eine Defragementierung durchführen.

Bei XFS gibt es zum Beispiel das Tool »xfs_fsr« , das die Extent-Aufteilung reorganisiert. Ein praktisches Features des Programms ist, dass man ihm mitteilen kann, wie lange es laufen soll, und beim nächsten Start macht es na der Stelle weiter, wo es aufgehört hat. Online-Defragmentierung bei Ext4 befindet sich noch in der Entwicklung, steht aber kurz vor der Fertigstellung. Auch ein Tool namens »e4defrag« , mit dem sich einzelne Dateien defragmentieren lassen, ist noch nicht völlig ausgereift und benötigt zur effizienten Arbeit noch besseren Kernel-Support [3] . Nach Aussagen von Ext4-Entwickler Ted T'so erzeugt es beim aktuellen Stand der Entwicklung eine neue Datei von der Größe der zu fragmentierenden, vergleicht den Grad der Fragmentierung und ersetzt gegebenenfalls die alte durch die neue Datei.