BEZEICHNUNG¶

xfs - Layout, Einhänge-Optionen und unterstützte Dateiattribute für das XFS-Dateisystem

BESCHREIBUNG¶

Ein XFS-Dateisystem kann sich auf einer regulären Festplattenpartition befinden oder auf einem logischen Datenträger. Ein XFS-Dateisystem besteht aus bis zu drei Teilen: einer Daten-Sektion, einer Protokoll-Sektion und einer Echtzeit-Sektion. Werden die Grundeinstellungen von mkfs.xfs(8) genutzt, ist die Echtzeit-Sektion nicht vorhanden und der Protokoll-Bereich ist in der Daten-Sektion enthalten. Die Protokoll-Sektion kann entweder separat von der Daten-Sektion sein, oder darin enthalten. Die Dateisystem-Sektionen sind aufgeteilt in eine bestimmte Anzahl von Blöcken, deren Größe beim Aufruf von mkfs.xfs(8) durch die Option -b angegeben wird.

Die Daten-Sektion enthält sowohl alle Metadaten des Dateisystems (Inodes, Verzeichnisse, indirekte Blöcke), wie auch die Daten von Dateien der Benutzer für gewöhnliche (nicht-Echtzeit) Dateien. Hinzu kommt der Protokollbereich, sofern das Protokoll intern zur Daten-Sektion liegt. Die Daten-Sektion ist unterteilt in eine Anzahl von Allokations-Gruppen. Die Anzahl und Größe dieser Allokations-Gruppen werden durch mkfs.xfs(8) bestimmt, so dass im Normalfall eine kleine Anzahl gleich großer Gruppen entsteht. Die Anzahl der Allokations-Gruppen beeinflusst den Grad der verfügbaren Parallelität in Datei- und Blockzuweisung. Bei ausreichend Speicher und viel Allokations-Aktivität sollte diese Anzahl gegenüber dem Ausgangswert erhöht werden. Die Anzahl der Allokations-Gruppen sollte nicht sehr hoch angesetzt werden, da dann durch das Dateisystem sehr viel CPU-Zeit in Anspruch genommen wird, besonders wenn das Dateisystem nahezu voll ist. Durch den Aufruf von xfs_growfs(8) werden mehr Allokations-Gruppen (in der Originalgröße) hinzugefügt.

Die Protokoll-Sektion (oder auch Bereich, wenn sie sich in der Daten-Sektion befindet) wird genutzt, um im laufenden Dateisystem Änderungen an den Metadaten des Dateisystems zu speichern, bis diese Änderungen auf die Daten-Sektion angewandt wurden. Im Normalbetrieb wird sequentiell geschrieben, während des Einhängens ist die Protokoll-Sektion allerdings schreibgeschützt. Wird ein Dateisystem nach einem Absturz eingehängt, wird das Protokoll gelesen, um jene Aktionen abzuschließen, die sich zur Zeit des Absturzes in Bearbeitung befanden.

Die Echtzeit-Sektion wird genutzt, um die Daten von Echtzeit-Dateien zu speichern. Durch xfsctl(3) wurde diesen Dateien nach Dateierzeugung ein Attribut-Bit gesetzt, noch bevor irgendwelche Daten in die Datei geschrieben wurden. Die Echtzeit-Sektion ist unterteilt in eine Anzahl von Extents fixer Größe (spezifiziert zur Zeit des Aufrufs von mkfs.xfs(8)). Jede Datei in der Echtzeit-Sektion hat eine Extent-Größe, die ein Vielfaches der Extent-Größe der Echtzeit-Sektion ist.

Jede Allokations-Gruppe beinhaltet mehrere Datenstrukturen. Der erste Sektor enthält den Superblock. Für alle auf die erste folgenden Allokations-Gruppen ist der Superblock nur eine Kopie und wird nicht nach einem Aufruf von mkfs.xfs(8) aktualisiert. Die nächsten drei Sektoren enthalten Informationen über Block- und Inode-Zuweisungen innerhalb der Allokations-Gruppe. Außerdem befinden sich noch Datenstrukturen zur Lokalisierung freier Blöcke und Inodes in jeder Allokations-Gruppe; diese werden anhand ihrer Header-Strukturen ausfindig gemacht.

Jedes XFS-Dateisystem ist durch einen universellen eindeutigen Identifizierer (UUID) gekennzeichnet. Diese UUID ist im Header einer jeden Allokations-Gruppe gespeichert und dient zur Unterscheidung der verschiedenen XFS-Dateisysteme, weshalb es vermieden werden sollte, XFS-Dateisysteme mit dd(1) oder anderen blockbasierten Kopierprogrammen zu kopieren. Falls zwei XFS-Dateisysteme auf der selben Maschine die selbe UUID hätten, bekäme das Programm xfsdump(8) Schwierigkeiten bei der Ausführung inkrementeller und wieder aufgenommener (»resumed«) Dumps. Um Kopien von XFS-Dateisystemen zu erstellen, werden xfsdump(8) und xfsrestore(8) empfohlen. Um einen Schnappschuss eines bereits eingehängten Dateisystems einzuhängen, könnte die Angabe der Option nouuid für mount(8) notwendig sein.

AKTIONEN¶

Einige für das XFS-Dateisystem spezifische Funktionen sind für Anwendungen durch die xfsctl(3)- und open_by_handle(3)-Schnittstellen verfügbar.

EINHÄNGEOPTIONEN¶

Die folgenden XFS-spezifischen Einhänge-Optionen können beim Einhängen eines XFS-Dateisystems genutzt werden. Weitere allgemeingültige Optionen stehen zur Verfügung; für weitere Details wenden Sie sich bitte an die Handbuchseite mount(8).

allocsize=Größe

Legt für den Fall der verzögerten Allokation die Größe der Vorabbelegung bis Dateiende für gepufferte E/A fest. Gültige Werte für diese Option liegen zwischen Seitengröße (typischerweise 4 KiB) und 1 GiB inklusive - in Zweierpotenz-Schritten.

Per Vorgabe wird die Größe der Vorabbelegung bis Dateiende dynamisch zugewiesen. Dieses Verhalten nutzt eine Reihe von Heuristiken, um die Größe der Vorabbelegung zu optimieren. Diese Heuristiken basieren auf den aktuellen Allokationsmustern innerhalb der Datei und den Zugriffsmustern auf die Datei. Ein fester Wert für allocsize schaltet das dynamische Verhalten ab.

attr2|noattr2

Hinweis: Diese Optionen wurden mit Kernelversion 5.10 als veraltet markiert. Die Option noattr2 wird nicht vor September 2025 entfernt und die Option attr2 wird die unveränderbare Vorgabe.

Diese Optionen schalten eine »opportunistische« Verbesserung an bzw. aus, die darauf abzielt, die Art zu verändern, in der erweiterte »inline«-Attribute auf der Festplatte gespeichert werden. Wird die neue Form zum ersten Mal durch Übergabe von attr2 verwendet (entweder beim Setzen oder Entfernen erweiterter Attribute), so wird im Superblock der Festplatte das entsprechende Bitfeld aktualisiert.

Das Standard-Verhalten wird durch das Funktionalitäts-Bit auf der Platte bestimmt. Es zeigt an, ob das attr2-Verhalten aktiviert ist. Falls eine der Einhänge-Optionen gesetzt wurde, dann wird diese zum neuen Vorgabewert für das Dateisystem.

Dateisysteme mit aktiviertem CRC nutzen immer das attr2-Format, und werden daher die noattr2-Einhänge-Option zurückweisen, sofern gesetzt.

dax=Wert

Setzt das Verhalten des direkten CPU-Zugriffs (DAX) für das aktuelle Dateisystem. Diese Einhängeoption akzeptiert die folgenden Werte:

»dax=inode«: DAX wird nur auf regulären Dateien mit angewandtem FS_XFLAG_DAX aktiviert.

»dax=never«: DAX wird für keine Datei aktiviert. FS_XFLAG_DAX wird ignoriert.

»dax=always«: DAX wird für alle regulären Dateien aktiviert, unabhängig vom FS_XFLAG_DAX-Zustand.

Wenn beim Einhängen eines Dateisystems auf einem DAX-fähigen Gerät keine Option verwandt wird, dann wird dax=inode als Vorgabe verwandt.

Details zum DAX-Verhalten im Kernel finden Sie in der Kerneldokumentation in filesystems/dax.txt.

discard|nodiscard

Aktiviert/deaktiviert das Erteilen von Befehlen, mit denen das Dateisystem freien Speicher zurückfordert. Dies ist bei SSD-Geräten nützlich, bei »thin provisioned« LUNs und bei Abbildern von virtuellen Maschinen, kann allerdings Einfluss auf die Performance haben.

Anmerkung: Aktuell wird empfohlen, die Anwendung fstrim(8) zu verwenden, um ungenutzte Blöcke zu entfernen. Der Einfluss auf die Performance durch diese Option ist gravierend. Aus diesem Grunde is nodiscard die Vorgabe.

grpid|bsdgroups|nogrpid|sysvgroups

Diese Optionen bestimmen, welche Gruppen-ID eine neu erstellte Datei erhält. Wenn grpid gesetzt ist, erhält die Datei die Gruppen-ID des Verzeichnisses, in dem sie erzeugt wird; anderenfalls erhält sie die fsgid des aktuellen Prozesses, sofern das Verzeichnis nicht das Setgid-Bit gesetzt hat. In diesem Fall erbt die Datei die GID des Eltern-Verzeichnisses, und auch das Setgid-Bit, falls es sich um ein Verzeichnis handelt.

filestreams

Veranlasst den Datenzuteiler, den Dateistrom-Allokationsmodus über das gesamte Dateisystem hinweg zu benutzen, anstatt nur in entsprechend konfigurierten Verzeichnissen.

ikeep|noikeep

Hinweis: Diese Optionen wurden mit Kernelversion 5.10 als veraltet markiert. Die Option noikeep wird nicht vor September 2025 entfernt und die Option ikeep wird die unveränderbare Vorgabe.

Wenn ikeep angegeben wurde, löscht XFS leere Inode-Cluster nicht und behält sie stattdessen auf der Festplatte. Wenn noikeep angegeben wurde, werden leere Inode-Cluster zurück in den Pool von verfügbarem Speicher gegeben. noikeep ist der Vorgabewert.

inode32|inode64

Wird inode32 angegeben, zeigt es an, dass XFS das Erzeugen von Inodes auf Orte beschränkt, die keine Inode-Nummern mit einer Wertigkeit größer als 32 Bit hervorbringen werden.

Wird inode64 übergeben, zeigt es an, dass es XFS erlaubt ist, Inodes auch an Orten im Dateisystem zu erstellen, deren Inode-Nummern mit höherer Wertigkeit als 32 Bit sein werden.

inode32 wird aus Gründen der Rückwärtskompatibilität zu älteren Systemen und Anwendungen angeboten, da 64-Bit-große Inode-Nummern Probleme bei jenen Anwendungen hervorrufen können, die keine großen Inode-Nummern verarbeiten können. Falls Anwendungen benutzt werden, die keine Inode-Nummern größer als 32 Bit verarbeiten können, sollte die inode32-Option angegeben werden.

Inode64 ist die Vorgabe für Kernel v3.7 und neuer.

largeio|nolargeio

Falls nolargeio übergeben wurde, wird die von stat(2) in st_blksize berichtete optimale E/A so klein wie möglich sein, um es Benutzer-Anwendungen zu ermöglichen, ineffiziente Lese-/Änderungs-/Schreib-E/A zu vermeiden. Typischerweise ist dies die Seitengröße der Maschine, da dies die Granularität des Seiten-Caches ist.

Falls largeio angegeben wurde, wird ein Dateisystem, das mit einem Wert für »swidth« erzeugt wurde, in st_blksize den Wert für swidth in Byte zurückgeben. Sollte das Dateisystem keinen Wert für swidth haben, jedoch einen Wert für »allocsize«, dann wird stattdessen allocsize in Byte zurückgegeben. Anderenfalls ist das Verhalten das gleiche wie bei nolargeio. nolargeio ist die Vorgabe.

logbufs=Wert

Setze die Anzahl von speicherinternen Protokollpuffern. Erlaubte Werte liegen im Bereich von 2–8 einschließlich.

Der Vorgabewert ist 8 Puffer.

Falls der Speicherbedarf von 8 Puffern für kleine Systeme zu groß ist, dann kann dieser Wert, auf Kosten der Performance bei Metadaten-intensiven Arbeitslasten, reduziert werden. Die Option logbsize weiter unten regelt die Größe jedes Puffers, und ist somit in diesem Falle auch von Bedeutung.

logbsize=Wert

Setzt die Größe jedes speicherinternen Protokollpuffers. Die Größe kann in Byte oder mit einem »k«-Suffix in KibiBytes (KiB) angegeben werden. Falls manuell gesetzt, muss logbsize eine der angegebenen gültigen Größen und ganzzahliges Vielfaches der Protokoll-Stripe-Einheit sein, die bei der Ausführung von Mkfs konfiguriert wurde.

Gültige Größen für Protokolle der Versionen 1 und 2 sind 16384 (Wert=16k) und 32768 (Wert=32k). Gültige Größen für Protokolle der Version 2 sind ferner: 65536 (Wert=64k), 131072 (Wert=128k) und 262144 (Wert=256k).

Der Vorgabewert für Protokolle der Version 1 ist 32768, während der Vorgabewert für Protokolle der Version 2 max(32768, log_sunit) ist, selbst wenn log_sunit nicht auf einen der obigen gültigen Werte passt.

logdev=Gerät und rtdev=Gerät

Für die Nutzung eines externen Protokolls (ein Metadaten-Journal) und/oder eines Echtzeit-Gerätes. Ein XFS-Dateisystem besteht aus bis zu drei Teilen: einer Daten-Sektion, einer Protokoll-Sektion und einer Echtzeit-Sektion. Die Echtzeit-Sektion ist optional und die Protokoll-Sektion kann separat von der Daten-Sektion oder in ihr enthalten sein.

noalign

Datenallokationen werden nicht an den Grenzen der Stripe-Einheiten ausgerichtet. Dies ist nur für Dateisysteme relevant, die mit Parametern für die Datenausrichtung (sunit, swidth) ungleich Null durch Mkfs erzeugt wurden.

norecovery

Das Dateisystem wird eingehängt, ohne die Protokoll-Wiederherstellung zu starten. Falls das Dateisystem nicht sauber ausgehängt wurde, kommt es voraussichtlich zu Inkonsistenzen, sofern es im Modus »norecovery« eingehängt wird. Auf einige Dateien oder Verzeichnisse könnte dadurch nicht mehr zugegriffen werden. Mit »norecovery« eingehängte Dateisysteme müssen schreibgeschützt eingehängt werden, oder das Einhängen wird fehlschlagen.

nouuid

Keine Überprüfung auf doppelt eingehängte Dateisysteme anhand der Dateisystem-UUID. Dies ist nützlich, um LVM-Schnappschuss-Datenträger einzuhängen, und wird häufig genutzt, um in Kombination mit »norecovery« schreibgeschützte Schnappschüsse einzubinden.

noquota

Forciert das Ausschalten jeglicher Kontingent-Buchführung bzw. jeglicher Kontingent-Durchsetzung innerhalb des Dateisystems.

uquota/usrquota/quota/uqnoenforce/qnoenforce

Aktiviert die Kontingent-Buchführung je Benutzer und die Obergrenzen werden optional durchgesetzt. Weitere Details finden Sie in xfs_quota(8).

gquota/grpquota/gqnoenforce

Aktiviert die Kontingent-Buchführung je Gruppe und die Obergrenzen werden optional durchgesetzt. Weitere Details finden Sie in xfs_quota(8).

pquota/prjquota/pqnoenforce

Aktiviert die Kontingent-Buchführung je Projekt und die Obergrenzen werden optional durchgesetzt. Weitere Details finden Sie in xfs_quota(8).

sunit=Wert and swidth=Wert

Dies wird genutzt, um die Stripe-Einheit und Stripe-Breite für ein RAID-Gerät oder einen Stripe-Datenträger festzulegen. »Wert« muss dabei in 512-Byte-Block-Einheiten angegeben werden. Diese Optionen sind nur für Dateisysteme von Belang, die mit Parametern für die Datenausrichtung ungleich Null erzeugt wurden.

Die übergebenen Parameter »sunit« und »swidth« müssen mit der vorhandenen Charakteristik der Dateisystem-Ausrichtung kompatibel sein. Allgemein bedeutet dies, dass die alleinig gültigen Änderungen an sunit eine Vergrößerung um ein Vielfaches einer Zweierpotenz sein müssen. Gültige Werte für swidth sind ein ganzzahliges Vielfaches eines gültigen sunit-Wertes.

Üblicherweise sind diese Einhänge-Optionen nur in einem Fall notwendig, nämlich dann, wenn die Geometrie eines darunterliegenden RAID-Gerätes verändert wurde. Dies geschieht beispielsweise durch das Hinzufügen einer neuen Festplatte zu einem RAID5-LUN, mit anschließendem Neuformen des LUNs.

swalloc

Datenallokationen werden aufgerundet und an die Grenzen der Stripe-Breite angepasst, wenn das aktuelle Dateiende erweitert wird, und die Dateigröße größer als die Stripe-Breite ist.

wsync

Falls angegeben, werden alle Vorgänge eines Dateisystem-Namensraums synchron ausgeführt. Dies stellt sicher, dass sich die Veränderung an dem Namensraum auf einem stabilen Speicher befindet, wenn die Namensraum-Transaktion (create, unlink, usw.) beendet ist. Dies ist in HV-Umgebungen nützlich, in denen ein Failover nicht dazu führen darf, dass den Clients während oder nach dem Failover-Ereignis ein inkonsistenter Namensraum präsentiert wird.

ENTFERNTE EINHÄNGE-OPTIONEN¶

Die folgenden Einhänge-Optionen wurden aus dem Kernel entfernt und werden bei der Verwendung Fehlverhalten hervorrufen. Einhänge-Optionen gelten über eine maßvolle Dauer hinweg als veraltet, bevor sie entfernt werden.

DATEIATTRIBUTE¶

Das XFS-Dateisystem unterstützt auf Linux-Systemen das Setzen folgender Datei-Attribute mittels chattr(1):

a - nur anhängen

A - keine Aktualisierungen der Zugriffszeit (Access-Time)

d - kein Speicherauszug (no dump)

i - unveränderlich (immutable)

S - synchrone Aktualisierung

Weitere Beschreibungen dieser Attributs-Schalter finden Sie in der Handbuchseite von chattr(1).

SIEHE AUCH¶

chattr(1), xfsctl(3), mount(8), mkfs.xfs(8), xfs_info(8), xfs_admin(8), xfsdump(8), xfsrestore(8).

ÜBERSETZUNG¶

Die deutsche Übersetzung dieser Handbuchseite wurde von Mathias F. Popp <mpo_manpages@protonmail.ch> und Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.