Union-Dateisysteme: Implementierungen, Teil I


Dieser Artikel wird Ihnen von LWN-Abonnenten zur Verfügung gestellt

Abonnenten von LWN.net haben diesen Artikel – und alles, was ihn umgibt – möglich gemacht. Wenn Sie unsere Inhalte schätzen, kaufen Sie bitte ein Abonnement und machen Sie die nächsten Artikel möglich.

März 25, 2009

Dieser Artikel wurde von Valerie Aurora (ehemals Henson) beigesteuert.

Im Artikel der letzten Woche habe ich die Anwendungsfälle, die grundlegenden Konzepte und die häufigen Designprobleme bei der Vereinigung von Dateisystemen besprochen. Diese Woche beschreibe ich mehrere Implementierungen von Unioning-Dateisystemen im technischen Detail. Die Unioning-Dateisysteme, die ich in diesem Artikel behandeln werde, sind Plan 9 Uniondirectories, BSD Union Mounts und Linux Union Mounts. Der nächste Artikel wird unionfs, aufs und möglicherweise ein oder zwei andere Unioning-Dateisysteme behandeln und die Serie abschließen.

Für jedes Dateisystem werde ich die grundlegende Architektur, die Funktionen und die Implementierung beschreiben. Die Diskussion über die Implementierung wird sich insbesondere auf Whiteouts und das Lesen von Verzeichnissen konzentrieren. Abschließend werde ich einen Blick auf die softwaretechnischen Aspekte der einzelnen Implementierungen werfen, z.B. Codegröße und -komplexität, Invasivität und Belastung der Dateisystementwickler.

Bevor Sie diesen Artikel lesen, sollten Sie sich Andreas Grünbachers soeben veröffentlichten Bericht über den Union Mount Workshop vom letzten November ansehen. Es ist eine gute Zusammenfassung der Unioning-Dateisystem-Funktionen, die für Distributionsentwickler am dringendsten sind. Aus der Einleitung: „Alle Anwendungsfälle, an denen wir interessiert sind, laufen im Grunde auf dasselbe hinaus: ein Image oder Dateisystem zu haben, das nur lesend verwendet wird (entweder weil es nicht beschreibbar ist oder weil das Schreiben in das Image nicht erwünscht ist), und so zu tun, als ob dieses Image oder Dateisystem beschreibbar wäre, und Änderungen irgendwo anders zu speichern.“

Plan 9 union directories

Das Plan 9 Betriebssystem (hier der Quellcode) implementiert unioning auf seine eigene spezielle Plan 9 Art. In Plan 9-Union-Verzeichnissen wird nur der oberste Verzeichnis-Namensraum zusammengeführt, keine Unterverzeichnisse. Unabhängig von UNIX-Standards implementieren Plan 9-Union-Verzeichnisse keine Whiteouts und filtern nicht einmal doppelte Einträge aus – wenn derselbe Dateiname in zwei Dateisystemen auftaucht, wird er in den Verzeichnislisten einfach zweimal angezeigt.

Ein Plan 9-Union-Verzeichnis wird wie folgt erstellt:

 bind -a /home/val/bin/ /bin

Das würde dazu führen, dass das Verzeichnis/home/val/bin„nach“ (der Option-a)/binunionmounted wird; andere Optionen sind, das neue Verzeichnis vor das bestehende Verzeichnis zu setzen oder das bestehende Verzeichnis ganz zu ersetzen. (Das scheint mir eine seltsame Anordnung zu sein, da ich es mag, wenn Befehle in meinem persönlichenbin/Vorrang vor den systemweiten Befehlen haben, aber das ist das Beispiel aus der Plan 9 Dokumentation). Brian Kernighane erklärt eine der Verwendungsmöglichkeiten von Unionsverzeichnissen: „Dieser Mechanismus der Unionsverzeichnisse ersetzt den Suchpfad der herkömmlichen UNIX-Shells. Soweit es Sie betrifft, befinden sich alle ausführbaren Programme in /bin.“ Unionsverzeichnisse können theoretisch viele Verwendungen der grundlegendenUNIX -Bausteine symbolische Links und Suchpfade ersetzen.

Ohne Whiteouts oder Duplikateliminierung ist readdir() die Implementierung von Unionsverzeichnissen trivial. Die Offsets der Verzeichniseinträge vom zugrundeliegenden Dateisystem entsprechen direkt dem Offset in Bytes des Verzeichniseintrags vom Anfang des Verzeichnisses. EinUnion-Verzeichnis wird so behandelt, als ob die Inhalte der zugrundeliegenden Verzeichnisse miteinander verkettet wären.

Plan 9 implementiert eine beachtenswerte Alternative zu readdir(), dirread().dirread() gibt Strukturen des Typs Dir zurück, die in der stat()-Manualseite beschrieben sind. Der wichtige Teil von Dir ist das Qid-Mitglied. Ein Qid ist:

…eine Struktur, die die Felder path und vers enthält: path ist garantiert eindeutig unter allen Pfadnamen, die sich derzeit auf dem Dateiserver befinden, und vers ändert sich jedes Mal, wenn die Datei geändert wird. Der Pfad ist ein long long (64 Bits, vlong) und vers ist ein unsigned long (32 Bits, ulong).

Warum ist das interessant? Einer der Gründe, warum readdir() so mühsam zu implementieren ist, ist, dass es das d_off-Mitglied von struct dirent zurückgibt, ein einzelnes off_t (32 Bits, es sei denn, die Anwendung ist mit Unterstützung für große Dateien kompiliert), um den Verzeichniseintrag zu markieren, in dem eine Anwendung beim nächsten readdir()Aufruf weiter lesen soll. Dies funktioniert gut, solange d_off ein einfacher Byte-Offset in eine flache Datei von weniger als 232 Bytes ist und bestehende Verzeichniseinträge nicht verschoben werden – was bei vielen modernen Dateisystemen (XFS, btrfs, ext3 mit htree-Indizes) nicht der Fall ist. Das96-Bit Qid ist eine viel nützlichere Platzmarkierung als das 32- oder 64-Bit off_t. Eine gute Zusammenfassung der Probleme, die mit der Implementierung von readdir() verbunden sind, finden Sie in TheodoreY. Ts’o’s ausgezeichneten Beitrag zu diesem Thema auf der btrfs-Mailingliste.

Aus Sicht der Softwaretechnik sind Plan 9-Union-Verzeichnisse himmlisch. Ohne Whiteouts, Eliminierung von doppelten Einträgen, komplizierte Verzeichnis-Offsets oder das Zusammenführen von Namensräumen über das Top-Level-Verzeichnis hinaus ist die Implementierung einfach und leicht zu pflegen.Allerdings müsste jede praktische Implementierung von Unioning-Dateisystemen für Linux (oder jedes andere UNIX) diese Probleme lösen. Für unsere Zwecke dienen die Union-Directories von Plan 9 in erster Linie als Inspiration.

BSD union mounts

BSD implementiert zwei Formen des Unioning: die"-o union"Option zummountBefehl, die ein Unioning-Directory ähnlich dem von Plan 9 erzeugt, und denmount_unionfsBefehl, der ein Unioning-Dateisystem mit mehr Funktionen implementiert, mit Whiteouts und Zusammenführung des gesamten Namensraums. Wir werden uns auf den letzteren konzentrieren.

Für diesen Artikel verwenden wir zwei Quellen für spezifische Implementierungsdetails: die ursprüngliche BSD-Union-Mount-Implementierung, wie sie im USENIX-PaperUnionmounts in 4.4BSD-Lite von 1995 beschrieben wird, und die FreeBSD7.1 mount_unionfs-Manpage und den Quellcode. AndereBSDs können davon abweichen.

Ein Verzeichnis kann entweder „unterhalb“ oder „oberhalb“ eines bestehenden Verzeichnisses oder Unionmounts gemountet werden, solange der oberste Zweig einer beschreibbaren Union beschreibbar ist. Es werden zwei Arten von Whiteouts unterstützt: entweder wird ein Whiteout immer erstellt, wenn ein Verzeichnis entfernt wird, oder es wird nur erstellt, wenn ein anderer Verzeichniseintrag mit diesem Namen in einem Zweig unterhalb des beschreibbaren Zweigs existiert. Es werden drei Modi unterstützt, um die Eigentümerschaft und den Modus von hochkopierten Dateien festzulegen. Der einfachste isttransparent, bei dem die neue Datei denselben Eigentümer und Modus wie das Original behält. Der Modus masquerade macht die kopierten Dateien zum Eigentum eines bestimmten Benutzers und unterstützt eine Reihe von Einhängeoptionen zur Bestimmung des neuen Dateimodus.traditional setzt den Eigentümer auf den Benutzer, der den Union-Mount-Befehl gegeben hat, und setzt den Modus entsprechend der umask zum Zeitpunkt des Union-Mounts.

Wenn ein Verzeichnis geöffnet wird, wird ein gleichnamiges Verzeichnis auf der obersten beschreibbaren Ebene angelegt, wenn es nicht bereits existiert. Aus dem Papier:

Durch die aggressive Erstellung von Schattenverzeichnissen während der Suche vermeidet das Unionfilesystem, dass die Kette von Verzeichnissen von der Wurzel der Einhängung bis zum Punkt des Kopierens geprüft und möglicherweise erstellt werden muss.Da der von einem Verzeichnis verbrauchte Speicherplatz vernachlässigbar ist, schien es eine bessere Alternative zu sein, Verzeichnisse zu erstellen, wenn sie zum ersten Mal durchlaufen wurden.

Als Ergebnis wird ein "find /union" dazu führen, dass alle Verzeichnisse (aber keine Verzeichniseinträge, die auf Nicht-Verzeichnisse zeigen) in die beschreibbare Schicht kopiert werden. Für die meisten Dateisystem-Images wird dies eine vernachlässigbare Menge an Speicherplatz verbrauchen (weniger als z.B. der für den Root-Benutzer reservierte Platz oder der Platz, der von unbenutzten Inodes in einem FFS-artigen Dateisystem eingenommen wird).

Eine Datei wird in die oberste Schicht kopiert, wenn sie mit Schreibberechtigung geöffnet wird oder die Dateiattribute geändert werden. (Da Verzeichnisse kopiert werden, wenn sie geöffnet werden, ist gewährleistet, dass das enthaltende Verzeichnis bereits auf der beschreibbaren Ebene existiert.) Wenn die zu kopierende Datei mehrere harte Links hat, werden die anderen Links ignoriert und die neue Datei hat eine Linkanzahl von eins. Dies kann Anwendungen stören, die harte Links verwenden und erwarten, dass Änderungen über einen Link-Namen angezeigt werden, wenn sie über einen anderen harten Link referenziert werden. Solche Anwendungen sind relativ selten, aber niemand hat eine systematische Studie durchgeführt, um herauszufinden, welche Anwendungen in dieser Situation versagen.

Whiteouts werden mit einem speziellen Verzeichniseintragstyp, DH_WHT, implementiert. Whiteout-Verzeichniseinträge verweisen auf keinen echten Inode, aber für eine einfache Kompatibilität mit existierenden Dateisystem-Hilfsmitteln wie fsck, enthält jeder Whiteout-Verzeichniseintrag eine falsche Inode-Nummer, die WINO reservierte Whiteout-Inode-Nummer. Das zugrunde liegende Dateisystem muss modifiziert werden, um den Whiteout-Verzeichniseintragstyp zu unterstützen. Neue Verzeichnisse, die einen Whiteout-Eintrag ersetzen, werden über ein neues „opaque“-Inode-Attribut als undurchsichtig markiert, so dass Suchvorgänge nicht durch sie hindurchgehen (was wiederum minimale Unterstützung durch das zugrunde liegende Dateisystem erfordert).

Doppelte Verzeichniseinträge und Whiteouts werden in der Userspacereaddir()-Implementierung behandelt. Zur opendir()Zeit liest die C-Bibliothek das Verzeichnis auf einmal, entfernt Duplikate, wendet Whiteouts an und speichert die Ergebnisse.

BSD-Union-Mounts versuchen nicht, Änderungen an Zweigen unterhalb des beschreibbaren oberen Zweiges zu behandeln (obwohl sie erlaubt sind). Die Art und Weise, wie rename() behandelt wird, ist nicht beschrieben.

Ein Beispiel aus der mount_unionfs Manpage:

 The commands mount -t cd9660 -o ro /dev/cd0 /usr/src mount -t unionfs -o noatime /var/obj /usr/src mount the CD-ROM drive /dev/cd0 on /usr/src and then attaches /var/obj on top. For most purposes the effect of this is to make the source tree appear writable even though it is stored on a CD-ROM. The -o noatime option is useful to avoid unnecessary copying from the lower to the upper layer.

Ein weiteres Beispiel (mit dem Hinweis, dass ich glaube, dass die Versionskontrolle am besten außerhalb des Dateisystems implementiert wird):

 The command mount -t unionfs -o noatime -o below /sys $HOME/sys attaches the system source tree below the sys directory in the user's home directory. This allows individual users to make private changes to the source, and build new kernels, without those changes becoming visible to other users.

Linux-Union-Mounts

Wie BSD-Union-Mounts, implementieren Linux-Union-Mounts Dateisystem-Unioning in der VFS-Schicht, mit einiger kleinerer Unterstützung von darunterliegenden Dateisystemen für Whiteouts und undurchsichtige Verzeichnis-Tags. Es existieren mehrere Versionen dieser Patches, die unter anderem von Jan Blunck, Bharata B. Rao und Miklos Szeredi geschrieben und modifiziert wurden.

Eine Version dieses Codes führt nur die Verzeichnisse der obersten Ebene zusammen, ähnlich wie Plan 9 Union Directories und die BSD -o unionMount Option. Diese Version von Union Mounts, die ich als Uniondirectories bezeichne, wird in einem kürzlich erschienenen LWN-Artikel von Goldwyn Rodrigues und in Miklos Szeredis jüngstem Posting eines aktualisierten Patch-Sets ausführlich beschrieben. Für den Rest dieses Artikels werden wir uns auf Versionen von Unionmounts konzentrieren, die den vollständigen Namensraum zusammenführen.

Linux Unionmounts befinden sich derzeit in aktiver Entwicklung. Dieser Artikel beschreibt die von Jan Blunck veröffentlichte Version gegen Linux2.6.25-mm1, util-linux 2.13 und e2fsprogs 1.40.2. Die Patch-Sets, als Quilt-Serie, können von Jans ftp-Seite heruntergeladen werden:

Kernel patches: ftp://ftp.suse.com/pub/people/jblunck/patches/

Utilities: ftp://ftp.suse.com/pub/people/jblunck/union-mount/

Ich habe eine Webseite mit Links zu den Git-Versionen der oben genannten Patches und einer Dokumentation im HOWTO-Stil unter http://valerieaurora.org/union erstellt.

Eine Union wird erstellt, indem ein Dateisystem mit dem MS_UNION-Flagsatz eingehängt wird (MS_BEFORE, MS_AFTER und MS_REPLACE sind in der mount-Codebasis definiert, werden aber derzeit nicht verwendet). Wenn das MS_UNION-Flag angegeben ist, muss das eingehängte Dateisystem entweder schreibgeschützt sein oder Whiteouts unterstützen. In dieser Version von Union-Mounts wird das Union-Mountflag durch die Option „-o union“ zu mount angegeben. Um zum Beispiel eine Vereinigung von zwei Loopbackdevice-Dateisystemen, /img/ro und /img/rw, zu erstellen, würden Sie folgendes ausführen:

 # mount -o loop,ro,union /img/ro /mnt/union/ # mount -o loop,union /img/rw /mnt/union/

Jeder Union-Mount erstellt einstruct union_mount:

 struct union_mount {atomic_t u_count;/* reference count */struct mutex u_mutex;struct list_head u_unions;/* list head for d_unions */struct hlist_node u_hash;/* list head for searching */struct hlist_node u_rhash;/* list head for reverse searching */struct path u_this;/* this is me */struct path u_next;/* this is what I overlay */ };

Wie inDocumentation/filesystems/union-mounts.txtbeschrieben, „werden alle Union_mount-Strukturen in zwei Hash-Tabellen zwischengespeichert, eine für die Suche nach der nächst niedrigeren Schicht des Union-Stacks und eine für die umgekehrte Suche nach der nächst höheren Schicht des Union-Stacks.“

Whiteouts und undurchsichtige Verzeichnisse werden auf die gleiche Weise implementiert wie in BSD. Das zugrundeliegende Dateisystem muss Whiteouts explizit unterstützen, indem es die Inode-Operation .whiteout für Verzeichnisse definiert (derzeit sind Whiteouts nur für ext2, ext3 und tmpfs implementiert). ext2 und ext3 verwenden den Whiteout-Verzeichnis-Eintragstyp DT_WHT, der seit Jahren in include/linux/fs.h definiert ist, aber bisher außerhalb des Coda-Dateisystems nicht verwendet wurde. Eine reservierte Whiteout-Inodennummer, EXT3_WHT_INO, ist definiert, wird aber noch nicht verwendet; Whiteout-Einträge weisen derzeit einen normalen Inode zu. Ein neues Inodeflag, S_OPAQUE, wird definiert, um Verzeichnisse als undurchsichtig zu kennzeichnen; wie in BSD werden Verzeichnisse nur als undurchsichtig gekennzeichnet, wenn sie einen Whiteout-Eintrag ersetzen.

Dateien werden nach oben kopiert, wenn die Datei zum Schreiben geöffnet wird. Wenn nötig, wird jedes Verzeichnis im Pfad zur Datei in den obersten Zweig kopiert (copy-on-demand von Verzeichnissen). Derzeit wird das Hochkopieren nur für reguläre Dateien und Verzeichnisse unterstützt.

readdir() ist einer der schwächsten Punkte der aktuellen Implementierung. Es ist auf die gleiche Weise implementiert wie BSD union mountreaddir(), aber im Kernel. Das d_offFeld wird auf den Offset innerhalb des aktuellen unterliegenden Verzeichnisses gesetzt, abzüglich der Größen der vorherigen Verzeichnisse. Verzeichniseinträge aus Verzeichnissen unterhalb der obersten Ebene müssen mit den vorherigen Einträgen auf Duplikate oder Auslassungen überprüft werden. Wie derzeit implementiert, liest jeder readdir() (technisch gesehen getdents())-Systemaufruf alle vorherigen Verzeichniseinträge in einen kerninternen Cache und vergleicht dann jeden zurückzugebenden Eintrag mit denen, die sich bereits im Cache befinden, bevor er in den Benutzerpuffer kopiert wird. Das Endergebnis ist, dass readdir() komplex und langsam ist und potenziell viel Kernel-Speicher belegt.

Eine Lösung besteht darin, den BSD-Ansatz zu übernehmen und die Zwischenspeicherung, das Whiteout und die doppelte Verarbeitung im Userspace durchzuführen. Bharata B. Raois entwirft Unterstützung für Union Mount readdir() in der glibc. (Der POSIX-Standard erlaubt die Implementierung von readdir() auf der libc-Ebene, wenn der reine Kernel-Systemaufruf nicht alle Anforderungen erfüllt.) Auf diese Weise würde die Speichernutzung in die Anwendung verlagert und der Cache wäre beständig. Eine andere Lösung wäre, den Cache im Kernel auf irgendeine Weise persistent zu machen.

Mein Vorschlag ist, eine Technik aus BSD-Union-Mounts zu nehmen und sie zu erweitern: proaktiv nicht nur Verzeichniseinträge für Verzeichnisse, sondern alle Verzeichniseinträge von niedrigeren Dateisystemen hochzukopieren, Duplikate und Whiteouts zu verarbeiten, das Verzeichnis undurchsichtig zu machen und es auf die Platte zu schreiben. Tatsächlich verarbeiten Sie die Verzeichniseinträge beim ersten Öffnen des Verzeichnisses auf Auslassungen und Duplikate und schreiben dann den resultierenden „Cache“ von Verzeichniseinträgen auf die Festplatte. Die Verzeichniseinträge, die auf Dateien in den zugrundeliegenden Dateisystemen verweisen, müssen auf irgendeine Weise signalisieren, dass es sich um „Fall-through“-Einträge handelt (das Gegenteil eines Whiteouts – es fordert explizit dazu auf, ein Objekt in einem niedrigeren Dateisystem nachzuschlagen). Ein Nebeneffekt dieses Ansatzes ist, dass Whiteouts überhaupt nicht mehr benötigt werden.

Ein Problem, das mit diesem Ansatz gelöst werden muss, ist die Darstellung von Verzeichniseinträgen, die auf untergeordnete Dateisysteme verweisen. Hier bieten sich mehrere Lösungen an: Der Eintrag könnte auf eine reservierte Inode-Nummer verweisen, das Dateisystem könnte für jeden Eintrag eine Inode zuweisen, diese aber mit einem neuen S_LOOKOVERTHERE Inode-Attribut kennzeichnen, es könnte einen Symlink auf ein reserviertes Ziel erstellen, usw. Dieser Ansatz würde mehr Platz auf dem darüberliegenden Dateisystem verbrauchen, aber alle anderen Ansätze erfordern die Zuweisung desselben Platzes im Speicher, und im Allgemeinen ist der Speicher teurer als die Festplatte.

Ein weniger dringendes Problem bei der aktuellen Implementierung ist, dass die Inoden-Nummern beim Booten nicht stabil sind (siehe den vorherigen Artikel über die Vereinigung von Dateisystemen für Details, warum dies ein Problem ist).Wenn „Fall-through“-Verzeichnisse durch die Zuweisung einer Inode für jeden Verzeichniseintrag auf dem darunterliegenden Dateisystem implementiert werden, dann werden stabile Inoden-Nummern ein natürlicher Nebeneffekt sein. Eine andere Möglichkeit ist, eine persistente Inode-Map irgendwo zu speichern – vielleicht in einer Datei im obersten Verzeichnis oder in einem externen Dateisystem.

Hardlinks werden auf die gleiche Weise gehandhabt – oder besser gesagt, nicht gehandhabt – wie BSD-Union-Mounts. Auch hier ist nicht klar, wie viele Anwendungen davon abhängen, dass eine Datei über einen Hardlink-Pfad geändert wird und die Änderungen über einen anderen Hardlink-Pfad (im Gegensatz zu einem symbolischen Link) angezeigt werden. Die einzige Methode, die mir einfällt, um dies korrekt zu handhaben, ist, irgendwo auf der Festplatte einen dauerhaften Cache für die Inodes zu haben, die wir mit mehreren Hardlinks kennen.

Hier ist ein Beispiel, wie es funktionieren würde: Angenommen, wir starten eine Kopie von Inode 42 und stellen fest, dass er drei Links hat. Wir würden einen Eintrag für die Hardlink-Datenbank erstellen, der die Dateisystem-ID, die Knotennummer, die Anzahl der Links und die Inode-Nummer der neuen Kopie auf der obersten Ebene des Dateisystems enthält. Dieser Eintrag könnte in einer Datei im CSV-Format oder als Symlink in einem reservierten Verzeichnis im Stammverzeichnis (z. B. „/.hardlink_hack/<fs_id>/42„, das ein Link zu „<new_inode_num> 3“ ist) oder in einer echten Datenbank gespeichert werden. Jedes Mal, wenn wir einen Inode auf einem zugrundeliegenden Dateisystem öffnen, suchen wir ihn in unserer Hardlink-Datenbank; wenn ein Eintrag vorhanden ist, verringern wir die Anzahl der Links und erstellen einen Hardlink zum richtigen Inode auf dem neuen Dateisystem. Wenn alle Pfade gefunden sind, sinkt die Anzahl der Links auf eins und der Eintrag kann aus der Datenbank gelöscht werden. Das Schöne an diesem Ansatz ist, dass der Overhead begrenzt ist und vollständig verschwindet, wenn alle Pfade zu den relevanten Inodes gefunden wurden. Allerdings führt dies immer noch eine beträchtliche Menge an möglicherweise unnötiger Komplexität ein; die BSD-Implementierung zeigt, dass viele Anwendungen gerne mit einem nicht ganz POSIXLY-korrekten Hardlink-Verhalten laufen.

Gegenwärtig gibt rename() von Verzeichnissen über Verzweigungen hinweg EXDEV zurück, der Fehler für den Versuch, eine Datei über verschiedene Dateisysteme hinweg umzubenennen. Der Benutzerbereich behandelt dies normalerweise transparent (da er diesen Fall bereits für Verzeichnisse aus verschiedenen Dateisystemen behandeln muss) und fällt darauf zurück, den Inhalt des Verzeichnisses einzeln zu kopieren. Das rekursive rename() von Verzeichnissen über Verzweigungen hinweg im Kernel zu implementieren, ist aus den gleichen Gründen wie das Umbenennen über reguläre Dateisysteme hinweg keine gute Idee; wahrscheinlich ist das Zurückgeben von EXDEV die beste Lösung.

Aus softwaretechnischer Sicht scheinen Union Mounts ein vernünftiger Kompromiss zwischen Funktionen und Wartungsfreundlichkeit zu sein. Die meisten der VFS-Änderungen sind in fs/union.c, einer Datei mit etwa 1000 Zeilen, untergebracht. Etwa 1/3 dieser Datei ist die Kernel-Implementierung readdir(), die mit ziemlicher Sicherheit vor einer möglichen Zusammenführung durch etwas anderes ersetzt wird. Das Haupthindernis für die Zusammenführung dieses Codes ist die readdir()-Implementierung. Ansonsten haben sich die Dateisystembetreuer deutlich positiver über Union Mounts geäußert als über jede andere Unioning-Implementierung.

Eine schöne Zusammenfassung von Union Mounts findet sich in Bharata B. Raos Union-Mount-Folien für FOSS.IN.

Nächstes Mal

Im nächsten Artikel werden wir unionfs und aufs besprechen und die verschiedenen Implementierungen von Unioning-Dateisystemen für Linux vergleichen. Staytuned!

Indexeinträge für diesen Artikel
Kernel Filesystems/Union
Kernel Union mounts
Gastartikel Aurora (Henson), Valerie

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.