Unix-Dateisystem - Unix File System

UFS
Entwickler CSRG
Vollständiger Name UNIX-Dateisystem
Eingeführt mit 4.2BSD
Strukturen
Verzeichnisinhalt Tabellen
Grenzen
max. Volumengröße 2 73 Byte (8 ZiB )
max. Dateigröße 2 73 Byte (8 ZiB )
max. Dateinamenlänge 255 Byte
Merkmale
Daten aufgezeichnet UFS1 und UFS2: letzte Zugriffszeit (atime), letzte Änderungszeit (mtime), letzte Inode-Änderungszeit (ctime), UFS2: Inode-Erstellungszeit (Geburtszeit)
Datumsbereich UFS1: 14. Dezember 1901–18. Januar 2038, UFS2: 64-Bit-Integer-Offset mit Vorzeichen von der Epoche
Datumsauflösung UFS1 und UFS2: Nanosekunde
Sonstiges
Unterstützte Betriebssysteme A/UX , DragonFly BSD , FreeBSD , FreeNAS , NAS4Free , HP-UX , NetBSD , NeXTSTEP , Linux , OpenBSD , illumos , Solaris , SunOS , Tru64 UNIX , UNIX System V und andere

Das Unix-Dateisystem ( UFS ) ist ein Dateisystem, das von vielen Unix- und Unix-ähnlichen Betriebssystemen unterstützt wird. Es ist ein entfernter Nachkomme des ursprünglichen Dateisystems, das von Version 7 Unix verwendet wurde .

Später wurde das Berkeley Fast File System (auch BSD Fast File SystemFFS genannt ) in Unixen verwendet, das nicht mit UFS identisch ist.

Entwurf

Ein UFS-Volume besteht aus den folgenden Teilen:

  • Einige Blöcke am Anfang der Partition, die für Bootblöcke reserviert sind (die getrennt vom Dateisystem initialisiert werden müssen)
  • Ein Superblock, der eine magische Zahl enthält , die dies als UFS-Dateisystem identifiziert, und einige andere wichtige Zahlen, die die Geometrie und Statistiken dieses Dateisystems und die Verhaltens-Tuning-Parameter beschreiben
  • Eine Sammlung von Zylindergruppen. Jede Zylindergruppe besteht aus folgenden Komponenten:
    • Eine Sicherungskopie des Superblocks
    • Ein Zylindergruppen-Header mit Statistiken, freien Listen usw. zu dieser Zylindergruppe, ähnlich denen im Superblock
    • Eine Reihe von Inodes , von denen jeder Dateiattribute enthält
    • Eine Reihe von Datenblöcken

Inodes werden fortlaufend nummeriert, beginnend bei 0. Inode 0 ist für nicht zugeordnete Verzeichniseinträge reserviert, Inode 1 war in historischen UNIX-Versionen der Inode der Bad-Block-Datei, gefolgt vom Inode für das Stammverzeichnis , das immer Inode 2 ist und der Inode für das Verzeichnis lost+found, das Inode 3 ist.

Verzeichnisdateien enthalten nur die Liste der Dateinamen im Verzeichnis und den mit jeder Datei verknüpften Inode. Alle Dateimetadaten werden im Inode gehalten.

Geschichte und Entwicklung

Frühe Versionen von Unix-Dateisystemen wurden einfach als FS bezeichnet . FS umfasste nur den Bootblock, den Superblock, eine Ansammlung von Inodes und die Datenblöcke. Dies funktionierte gut für die kleinen Festplatten, für die frühe Unixe entwickelt wurden, aber als die Technologie weiterentwickelt wurde und die Festplatten größer wurden, verursachte das Hin- und Herbewegen des Kopfes zwischen der Ansammlung von Inodes und den Datenblöcken, auf die sie sich bezogen, ein Durcheinander . Marshall Kirk McKusick , damals ein Doktorand in Berkeley , optimierte das FFS (Fast File System) von BSD 4.2 , indem er Zylindergruppen erfand, die die Festplatte in kleinere Blöcke aufteilen, wobei jede Gruppe ihre eigenen Inodes und Datenblöcke hat.

Die Absicht von BSD FFS besteht darin zu versuchen, zugehörige Datenblöcke und Metadaten in derselben Zylindergruppe und idealerweise den gesamten Inhalt eines Verzeichnisses (sowohl Daten als auch Metadaten für alle Dateien) in derselben oder nahegelegenen Zylindergruppe zu lokalisieren Reduzierung der Fragmentierung, die durch das Verteilen des Inhalts eines Verzeichnisses über eine ganze Festplatte verursacht wird.

Einige der Leistungsparameter im Superblock umfassten die Anzahl der Spuren und Sektoren, die Plattenrotationsgeschwindigkeit, die Kopfgeschwindigkeit und die Ausrichtung der Sektoren zwischen den Spuren. In einem vollständig optimierten System könnte der Kopf zwischen nahen Spuren bewegt werden, um verstreute Sektoren aus abwechselnden Spuren zu lesen, während darauf gewartet wird, dass sich der Plattenteller dreht.

Als die Platten immer größer wurden, wurde die Optimierung auf Sektorebene obsolet (insbesondere bei Platten, die eine lineare Sektornummerierung und variable Sektoren pro Spur verwendeten). Bei größeren Festplatten und größeren Dateien wurden fragmentierte Lesevorgänge zu einem größeren Problem. Um dies zu bekämpfen, hat BSD ursprünglich die Blockgröße des Dateisystems von einem Sektor auf 1 K in 4.0 BSD erhöht; und in FFS die Blockgröße des Dateisystems von 1 K auf 8 K erhöht. Dies hat mehrere Auswirkungen. Die Wahrscheinlichkeit, dass die Sektoren einer Datei zusammenhängen, ist viel größer. Der Aufwand für das Auflisten der Blöcke der Datei wird reduziert, während die Anzahl von Bytes, die durch eine gegebene Anzahl von Blöcken darstellbar sind, erhöht wird.

Es sind auch größere Plattengrößen möglich, da die maximale Anzahl von Blöcken durch eine Blockanzahl mit fester Bitbreite begrenzt ist. Bei größeren Blockgrößen verschwenden jedoch Festplatten mit vielen kleinen Dateien Speicherplatz, da jede Datei mindestens einen Block belegen muss. Aus diesem Grund fügte BSD eine Fragmentierung auf Blockebene hinzu , die auch als Blocksuballocation, Tail Merging oder Tail Packing bezeichnet wird , bei der der letzte Teilblock von Daten aus mehreren Dateien in einem einzigen "Fragment" -Block gespeichert werden kann, anstatt in mehreren meist leeren Blöcken ( Allen 2005 ).

Implementierungen

Anbieter einiger proprietärer Unix-Systeme wie SunOS / Solaris , System V Release 4 , HP-UX und Tru64 UNIX sowie von offenen Unix abgeleitete Systeme wie illumos haben UFS übernommen. Die meisten von ihnen passten UFS an ihre eigenen Zwecke an und fügten proprietäre Erweiterungen hinzu, die von Unix-Versionen anderer Hersteller möglicherweise nicht erkannt werden. Viele haben weiterhin die ursprüngliche Blockgröße und Datenfeldbreite als das ursprüngliche UFS verwendet, sodass ein gewisses Maß an Lesekompatibilität über die Plattformen hinweg erhalten bleibt. Die Kompatibilität zwischen Implementierungen als Ganzes ist bestenfalls fleckig.

Ab Solaris 7 , Sun Microsystems enthalten UFS - Protokollierung, die geholten Dateisystem Journaling zu UFS, die in aktuellen Versionen von Solaris und Illumos noch verfügbar ist. Solaris UFS hat auch Erweiterungen für große Dateien und große Festplatten und andere Funktionen.

In davon abgeleiteten 4.4BSD- und BSD- Unix-Systemen wie FreeBSD , NetBSD , OpenBSD und DragonFlyBSD ist die Implementierung von UFS1 und UFS2 in zwei Schichten aufgeteilt: eine obere Schicht, die die Verzeichnisstruktur bereitstellt und Metadaten unterstützt (Berechtigungen, Eigentum, etc.) in der Inode-Struktur und untere Schichten, die als Inodes implementierte Datencontainer bereitstellen. Dies geschah, um sowohl das traditionelle FFS- als auch das LFS- Log-strukturierte Dateisystem mit gemeinsamem Code für gemeinsame Funktionen zu unterstützen. Die obere Schicht wird als "UFS" bezeichnet und die unteren Schichten werden als "FFS" und "LFS" bezeichnet. In einigen dieser Systeme wird der Begriff "FFS" für die Kombination der unteren FFS-Schicht und der oberen UFS-Schicht verwendet, und der Begriff "LFS" wird für die Kombination der unteren LFS-Schicht und der oberen UFS-Schicht verwendet.

Kirk McKusick implementierte die Blockneuzuweisung, eine Technik, die die Blöcke im Dateisystem kurz vor dem Schreiben neu anordnet, um die Fragmentierung zu reduzieren und die Alterung des Dateisystems zu kontrollieren. Er implementierte auch Soft-Updates , einen Mechanismus, der die Konsistenz des Dateisystems aufrechterhält, ohne die Leistung wie beim traditionellen Synchronisierungsmodus einzuschränken. Dies hat den Nebeneffekt, dass die Notwendigkeit einer Dateisystemprüfung nach einem Absturz oder Stromausfall reduziert wird. Um die verbleibenden Probleme nach einem Fehler zu beheben, wurde ein fsck-Hintergrunddienstprogramm eingeführt.

In UFS2 erweiterten Kirk McKusick und Poul-Henning Kamp die FreeBSD FFS- und UFS-Layer um 64-Bit-Blockzeiger (wodurch Volumes auf bis zu 8 Zebibyte anwachsen können ), Blöcke variabler Größe (ähnlich Extents ), erweiterte Flag-Felder, zusätzliche 'Geburtszeit'-Stempel, erweiterte Attributunterstützung und POSIX1.e-ACLs. UFS2 wurde ab FreeBSD 5.0 ​​zur Standard-UFS-Version. FreeBSD führte auch Soft-Updates und die Möglichkeit ein, Dateisystem- Snapshots sowohl für UFS1 als auch für UFS2 zu erstellen. Diese wurden seitdem auf NetBSD portiert, aber schließlich wurden weiche Updates (in NetBSD als weiche Abhängigkeiten bezeichnet) aus NetBSD 6.0 zugunsten des weniger komplexen Dateisystem-Journaling-Mechanismus namens WAPBL (auch als Logging bezeichnet) entfernt, der in NetBSD zu FFS hinzugefügt wurde 5.0. OpenBSD unterstützt seit Version 2.9 Soft-Updates und seit Version 4.2 UFS2 (FFS2)-Unterstützung (keine ACLs). OpenBSD hat UFS2 nun zur Standard-UFS-Version gemacht und wird in der Version 6.7 enthalten sein. Seit FreeBSD 7.0 unterstützt UFS auch das Journaling von Dateisystemen mit dem gjournal GEOM- Provider. FreeBSD 9.0 fügt zusätzlich zu Soft-Updates (SU+J) Unterstützung für leichtes Journaling hinzu, was den Bedarf an Hintergrund-fsck und NFSv4-ACLs stark reduziert.

FreeBSD, NetBSD, OpenBSD und DragonFly BSD enthalten auch das Dirhash- System, das von Ian Dowse entwickelt wurde. Dieses System unterhält eine speicherinterne Hash-Tabelle, um die Verzeichnissuche zu beschleunigen. Dirhash lindert eine Reihe von Leistungsproblemen, die mit großen Verzeichnissen in UFS verbunden sind.

Linux enthält eine UFS-Implementierung für die Binärkompatibilität auf Leseebene mit anderen Unixen, aber da es keine Standardimplementierung für die Herstellererweiterungen von UFS gibt, bietet Linux keine vollständige Unterstützung für das Schreiben auf UFS. Das native Linux- ext2- Dateisystem wurde von UFS1 inspiriert, unterstützt jedoch keine Fragmente und es gibt keine Pläne für die Implementierung von Soft-Updates. (In einigen von 4.4BSD abgeleiteten Systemen kann die UFS-Schicht eine ext2-Schicht als Containerschicht verwenden, genau wie sie FFS und LFS verwenden kann.)

NeXTStep , das von BSD abgeleitet war, verwendete auch eine Version von UFS. In Apple - s Mac OS X , es war , als Alternative zur Verfügung HFS + , ihre proprietären Dateisystem. Ab Mac OS X Leopard war es jedoch nicht mehr möglich, Mac OS X auf einem UFS-formatierten Volume zu installieren. Außerdem können ältere Versionen von Mac OS X, die auf UFS-formatierten Volumes installiert sind, nicht auf Leopard aktualisiert werden; Das Upgrade erfordert eine Neuformatierung des Startvolumes. In Mac OS X gab es ein Dateilimit von 4 GB für als UFS formatierte Festplatten. Ab Mac OS X Lion wurde die UFS-Unterstützung vollständig eingestellt.

Siehe auch

Verweise

Zitate

Literaturverzeichnis

Externe Links