12.3 Dateisysteme

Die Liste der Dateisysteme, die eingebunden werden sollen, steht im file-systems-Feld der Betriebssystemdeklaration (siehe Das Konfigurationssystem nutzen). Jedes Dateisystem wird mit der file-system-Form deklariert, etwa so:

(file-system
  (mount-point "/home")
  (device "/dev/sda3")
  (type "ext4"))

Wie immer müssen manche Felder angegeben werden – die, die im Beispiel oben stehen –, während andere optional sind. Die Felder werden nun beschrieben.

Datentyp: file-system

Objekte dieses Typs repräsentieren einzubindende Dateisysteme. Sie weisen folgende Komponenten auf:

type

Eine Zeichenkette, die den Typ des Dateisystems spezifiziert, z.B. "ext4".

mount-point

Der Einhängepunkt, d.h. der Pfad, an dem das Dateisystem eingebunden werden soll.

device

Hiermit wird die „Quelle“ des Dateisystems bezeichnet. Sie kann eines von drei Dingen sein: die Bezeichnung („Labels“) eines Dateisystems, die UUID-Kennung des Dateisystems oder der Name eines /dev-Knotens. Mit Bezeichnungen und UUIDs können Sie Dateisysteme benennen, ohne den Gerätenamen festzuschreiben²⁸.

Dateisystem-Bezeichnungen („Labels“) werden mit der Prozedur file-system-label erzeugt und UUID-Kennungen werden mit uuid erzeugt, während Knoten in /dev mit ihrem Pfad als einfache Zeichenketten aufgeführt werden. Hier ist ein Beispiel, wie wir ein Dateisystem anhand seiner Bezeichnung aufführen, wie sie vom Befehl e2label angezeigt wird:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (file-system-label "my-home")))

UUID-Kennungen werden mit der uuid-Form von ihrer Darstellung als Zeichenkette (wie sie vom Befehl tune2fs -l angezeigt wird) konvertiert²⁹ wie hier:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))

Wenn die Quelle eines Dateisystems ein zugeordnetes Gerät (siehe Zugeordnete Geräte) ist, muss sich das device-Feld auf den zugeordneten Gerätenamen beziehen – z.B. "/dev/mapper/root-partition". Das ist nötig, damit das System weiß, dass das Einbinden des Dateisystems davon abhängt, die entsprechende Gerätezuordnung hergestellt zu haben.

flags (Vorgabe: '())

Eine Liste von Symbolen, die Einbinde-Schalter („mount flags“) bezeichnen. Erkannt werden unter anderem read-only (nur lesbar), bind-mount (Verzeichniseinbindung), no-dev (Zugang zu besonderen Dateien verweigern), no-suid (setuid- und setgid-Bits ignorieren), no-atime (Dateizugriffs-Zeitstempel nicht aktualisieren), no-diratime (das Gleiche ausschließlich für Verzeichnisse), strict-atime (Dateizugriffs-Zeitstempel immer aktualisieren), lazy-time (Zeitstempel nur auf zwischengespeicherten Datei-Inodes im Arbeitsspeicher aktualisieren), no-exec (Programmausführungen verweigern) und shared (für Mehrfacheinhängungen). Siehe Mount-Unmount-Remount in Referenzhandbuch der GNU-C-Bibliothek für mehr Informationen zu diesen Einbinde-Schaltern.

options (Vorgabe: #f)

Entweder #f oder eine Zeichenkette mit Einbinde-Optionen („mount options“), die an den Dateisystemtreiber übergeben werden. Siehe Mount-Unmount-Remount in Referenzhandbuch der GNU-C-Bibliothek für Details.

Führen Sie man 8 mount aus, um die Einbinde-Optionen verschiedener Dateisysteme zu sehen. Aber aufgepasst: Wenn dort von „vom Dateisystem unabhängigen Einhängeoptionen“ die Rede ist, sind eigentlich Flags gemeint; sie gehören in das oben beschriebene flags-Feld.

Die Prozeduren file-system-options->alist und alist->file-system-options aus (gnu system file-systems) können benutzt werden, um als assoziative Liste dargestellte Dateisystemoptionen in eine Darstellung als Zeichenkette umzuwandeln und umgekehrt.

mount? (Vorgabe: #t)

Dieser Wert zeigt an, ob das Dateisystem automatisch eingebunden werden soll, wenn das System gestartet wird. Ist der Wert #f, dann erhält das Dateisystem nur einen Eintrag in der Datei /etc/fstab (welche vom mount-Befehl zum Einbinden gelesen wird), es wird aber nicht automatisch eingebunden.

needed-for-boot? (Vorgabe: #f)

Dieser boolesche Wert gibt an, ob das Dateisystem zum Hochfahren des Systems notwendig ist. In diesem Fall wird das Dateisystem eingebunden, wenn die initiale RAM-Disk (initrd) geladen wird. Für zum Beispiel das Wurzeldateisystem ist dies ohnehin immer der Fall.

check? (Vorgabe: #t)

Dieser boolesche Wert sagt aus, ob das Dateisystem vor dem Einbinden auf Fehler hin geprüft werden soll. Feineinstellungen, wie und wann geprüft wird, sind mit den folgenden Optionen möglich.

skip-check-if-clean? (Vorgabe: #t)

Wenn es wahr ist, zeigt dieser Boolesche Ausdruck an, ob eine durch check? ausgelöste Dateisystemüberprüfung direkt abbrechen darf, wenn das Dateisystem als in Ordnung („clean“) markiert ist, also zuvor korrekt ausgehangen wurde, so dass es keine Fehler enthalten dürfte.

Wenn Sie es auf falsch setzen, wird eine vollständige Konsistenzprüfung bei jedem Start erzwungen, wenn check? auf wahr gesetzt ist. Das kann sehr viel Zeit in Anspruch nehmen. Auf gesunden Systemen lassen Sie es besser eingeschaltet, sonst kann die Verlässlichkeit sogar abnehmen!

Andererseits speichern Dateisysteme wie fat nicht, ob der Rechner ordentlich heruntergefahren wurde, deswegen wird diese Option für sie ignoriert.

repair (Vorgabe: 'preen)

Wenn durch check? Fehler festgestellt wurden, kann es versuchen, das Dateisystem zu reparieren, und das System danach normal starten. Mit dieser Option legen Sie fest, wann und wie repariert werden soll.

Wenn es falsch ist, wird das Dateisystem möglichst unverändert gelassen. Beim Überprüfen mancher Dateisysteme wie jfs können trotzdem Schreibzugriffe auf das Gerät stattfinden, um die Aufzeichnungen über Operationen (das „Journal“) zu wiederholen. Es wird keine Reparatur versucht.

Wenn es #t ist, wird versucht, alle gefundenen Fehler zu beheben. Auf alle Rückfragen wird mit „yes“ geantwortet. Dadurch werden die meisten Fehler behoben, aber es kann schiefgehen.

Wenn es 'preen ist, werden nur solche Fehler behoben, wo auch ohne menschliche Aufsicht nichts Schlimmes passieren kann. Was das genau heißt, bleibt den Entwicklern des jeweiligen Dateisystems überlassen. Es kann auf dasselbe hinauslaufen wie keine oder alle Fehler zu beheben.

create-mount-point? (Vorgabe: #f)

Steht dies auf wahr, wird der Einhängepunkt vor dem Einbinden erstellt, wenn er noch nicht existiert.

mount-may-fail? (Vorgabe: #f)

Wenn dies auf wahr steht, bedeutet es, dass das Einbinden dieses Dateisystems scheitern kann, dies aber nicht als Fehler aufgefasst werden soll. Das braucht man in besonderen Fällen, zum Beispiel wird es für efivarfs benutzt, einem Dateisystem, das nur auf EFI-/UEFI-Systemen eingebunden werden kann.

dependencies (Vorgabe: '())

Dies ist eine Liste von <file-system>- oder <mapped-device>-Objekten, die Dateisysteme repräsentieren, die vor diesem Dateisystem eingebunden oder zugeordnet werden müssen (und nach diesem ausgehängt oder geschlossen werden müssen).

Betrachten Sie zum Beispiel eine Hierarchie von Einbindungen: /sys/fs/cgroup ist eine Abhängigkeit von /sys/fs/cgroup/cpu und /sys/fs/cgroup/memory.

Ein weiteres Beispiel ist ein Dateisystem, was von einem zugeordneten Gerät abhängt, zum Beispiel zur Verschlüsselung einer Partition (siehe Zugeordnete Geräte).

Scheme-Prozedur: file-system-label Zeichenkette

Diese Prozedur kapselt die Zeichenkette in einer opaken Dateisystembezeichnung:

(file-system-label "home")
⇒ #<file-system-label "home">

Mit Dateisystembezeichnungen werden Dateisysteme anhand ihrer Bezeichnung („Label“) statt ihres Gerätenamens („Device Name“) identifiziert. Siehe die Beispiele oben.

Das Modul (gnu system file-systems) exportiert die folgenden nützlichen Variablen.

Scheme-Variable: %base-file-systems

Hiermit werden essenzielle Dateisysteme bezeichnet, die für normale Systeme unverzichtbar sind, wie zum Beispiel %pseudo-terminal-file-system und %immutable-store (siehe unten). Betriebssystemdeklaration sollten auf jeden Fall mindestens diese enthalten.

Scheme-Variable: %pseudo-terminal-file-system

Das als /dev/pts einzubindende Dateisystem. Es unterstützt über openpty und ähnliche Funktionen erstellte Pseudo-Terminals (siehe Pseudo-Terminals in Referenzhandbuch der GNU-C-Bibliothek). Pseudo-Terminals werden von Terminal-Emulatoren wie xterm benutzt.

Scheme-Variable: %shared-memory-file-system

Dieses Dateisystem wird als /dev/shm eingebunden, um Speicher zwischen Prozessen teilen zu können (siehe shm_open in Referenzhandbuch der GNU-C-Bibliothek).

Scheme-Variable: %immutable-store

Dieses Dateisystem vollzieht eine Verzeichniseinbindung („bind mount“) des /gnu/store, um ihn für alle Nutzer einschließlich des Administratornutzers root nur lesbar zu machen, d.h. Schreibrechte zu entziehen. Dadurch kann als root ausgeführte Software, oder der Systemadministrator, nicht aus Versehen den Store modifizieren.

Der Daemon kann weiterhin in den Store schreiben, indem er ihn selbst mit Schreibrechten in seinem eigenen „Namensraum“ einbindet.

Scheme-Variable: %binary-format-file-system

Das binfmt_misc-Dateisystem, durch das beliebige Dateitypen als ausführbare Dateien auf der Anwendungsebene (dem User Space) zugänglich gemacht werden können. Es setzt voraus, dass das Kernel-Modul binfmt.ko geladen wurde.

Scheme-Variable: %fuse-control-file-system

Das fusectl-Dateisystem, womit „unprivilegierte“ Nutzer ohne besondere Berechtigungen im User Space FUSE-Dateisysteme einbinden und aushängen können. Dazu muss das Kernel-Modul fuse.ko geladen sein.

Das Modul (gnu system uuid) stellt Werkzeug zur Verfügung, um mit eindeutigen Identifikatoren für Dateisysteme umzugehen (sogenannten „Unique Identifiers“, UUIDs).

Scheme-Prozedur: uuid Zeichenkette [Typ]

Liefert eine eindeutige UUID (Unique Identifier) als opakes Objekt des angegebenen Typs (ein Symbol), indem die Zeichenkette verarbeitet wird:

(uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")
⇒ #<<uuid> type: dce bv: …>

(uuid "1234-ABCD" 'fat)
⇒ #<<uuid> type: fat bv: …>

Als Typ kann entweder dce, iso9660, fat, ntfs oder eines der üblichen Synonyme dafür angegeben werden.

UUIDs bieten eine andere Möglichkeit, sich in der Betriebssystemkonfiguration ohne Mehrdeutigkeiten auf eines der Dateisysteme zu beziehen. Siehe die Beispiele oben.