On Friday 07 November 2003 08:07, Ralf Corsepius wrote:
Das Hauptproblem: Fehlende Erfahrungswerte und praktisch nicht vorhandende Unterstützung durch die grossen Linux-Distributoren (Weder SuSE noch RH).
In Suse Linux ist XFS seit geraumer Zeit als vollwertiges Dateisystem integriert, und wird auch bei der Installation angeboten. Es ist jedoch nicht Default (der ist reiserfs).
Weiterhin gilt: Auch wenn xfs im Prinzip schon relativ alt ist, ist die Integration in Linux noch relativ jung und erforderte recht massive Eingriffe in den Kernel (Ich weiss nicht ob xfs mitterweile vollständig in den Kernel integriert sind. Lange Zeit waren recht massive Patches erforderlich, die nicht unerhebliche Probleme hatten ihren Weg in den Kernel zu finden, da sie recht massiv in den Kernel eingriffen.)
Ich kenne den Quelltext von XFS nicht, sondern nur die Whitepapers. Denen zufolge setzt XFS ein Buffer Cache System voraus, das von traditionellen Unix-Buffercaches sehr verschieden ist. Ich könnte mir vorstellen, daß dies der Grund für die von Dir beobachtete Duplizierung ist. Ein traditioneller Buffercache speichert Plattenblöcke im RAM, und tut dies unter der physikalischen Blockadresse. An jedem Cacheblock klebt also ein Tripel (major device number, minor device number, blocknummer). Dadurch wird sichergestellt, daß von einem Plattenblock nicht zwei Kopien im Cache existieren können und der Cache also konsistent gehalten werden kann. Beim Schreiben von neuen Datenblöcken wird jedoch ein neuer Block erst einmal in den Cache gelegt, um dann irgendwann später (bis zu 30 Sekunden später) zusammen mit allen anderen geänderten Blöcken auf die Platte geschrieben zu werden. Das hat aber zur Folge, daß jeder neue Block sofort layoutet werden muß, d.h. daß für jeden Block sofort eine physikalische Blockadresse auf der Platte gefunden werden muß. Programme schreiben nun in den meisten Fällen (immer, wenn keine Datenbankanwendung genutzt wird) ganze Dateien von vorne nach hinten durch. Es wäre nützlich für den Layouter des Dateisystems, wenn er solche Dateien auch am Stück layouten könnte, also nicht Block für Block ohne Kenntnis der Vorgänger oder Nachfolger positionieren müßte. XFS auf SGI organisiert den Buffercache also nicht nach physikalischen Blockadressen, sondern nach (major device number, minor device number, inode-nummer, logische Blocknummer in der Datei). Statt also (3, 1, 4711) für Block 4711 auf /dev/hda1 zu speichern, speichert XFS (3, 1, 0815, 2) für den 2. Block der Datei mit der Inode 0815 auf /dev/hda1. Das erlaubt es XFS, den Cache dateiweise zu flushen (Schreibe alle Blöcke der Datei mit der Inode 0815 von /dev/hda1) und diese Blöcke dann am Stück zu layouten. Die Layout-Entscheidung wird außerdem verzögert von dem Moment, wo der Block im Cache belegt wird zu dem Moment wo der Block aus dem Cache geflushed wird. Zu diesem Zeitpunkt ist aber der Kontext des Blocks (seine Vorgänger und Nachfolger) bereits bekannt und der Layouter kann diese zusätzliche Information verwenden um die Gesamtgröße der Allocation zu bestimmen. Da XFS außerdem seine freien Blöcke nicht in Bitmaps verwaltet, sondern in Extents (Paare von Startblock, Länge), und diese Extents nach Startblock und nach Länge in Bäumen indiziert, kann der XFS Layouter sehr schnell Extents in der für den Cache-Flush der Datei benötigten Länge bestimmen und die Datei "best-fit" unfragmentiert layouten. Das ist nach meinen Informationen ein Alleinstellungsmerkmal von XFS und wie gesagt für die interne Struktur von Unix Buffercaches sehr fremdartig. Ich habe keine Ahnung, ob dies mit dem eigentlichen XFS zusammen von SGI nach Linux portiert worden ist. Ich befürchte fast, daß dies nicht passiert ist, denn es hätte die VFS Cache-Layer vom Kernel komplett auf den Kopf gestellt. Wie gesagt, XFS in SGI ist von ca. 1994 oder so. Es ist also nun knapp 10 Jahre alt, und es ist allen anderen Ansätzen im Bereich Dateisysteme noch immer weit voraus (Und ich habe noch nicht mal angefangen von Streaming IO und der Guaranteed Rate I/O Layer zu erzählen, die leider nicht mit XFS zusammen nach Linux portiert worden ist). Kristian, leider niemals SGI benutzt habend