UNIX -Dateisystem
Entwickler (en) | CSRG |
---|---|
Vollständiger Name | UNIX -Dateisystem |
Eingeführt | mit 4.2bsd |
Strukturen | |
Verzeichnisinhalt | Tische |
Grenzen | |
Max. Volumengröße | 273 Bytes (8 Zib) |
Max. Dateigröße | 273 Bytes (8 Zib) |
Max. Dateiname Länge | 255 Bytes |
Merkmale | |
Daten aufgezeichnet | UFS1 und UFS2: Last Access Time (Atime), Last Modified Time (Mime), Last Inode Change Time (CTime), UFS2: Inode -Erstellungszeit (Geburtszeit)[1] |
Datumsbereich | UFS1: 14. Dezember 1901-18. Januar 2038, UFS2: 64-Bit Signed Integer Offset von Epoche[1] |
Datumslösung | UFS1 und UFS2: Nanosekunde[1] |
Sonstiges | |
Unterstützt Betriebssysteme | A/UX, Libelle BSD, Freebsd, Freenas, Nas4free, HP-UX, Netbsd, Nächster Schritt, Linux, OpenBSD, Illumos, Solaris, Sonnenos, Tru64 UNIX, UNIX -System v, und andere |
Das UNIX -Dateisystem (UFS) ist ein Dateisystem unterstützt von vielen Unix und Unix-artig Betriebssysteme. Es ist ein entfernter Nachkomme des Original -Dateisystemsystems, das von verwendet wird Version 7 Unix.
Später Berkeley schnelles Dateisystem (auch genannt BSD Schnelles Dateisystem — Ffs) wurde in Unixes verwendet, was nicht mit UFS entspricht.[2]
Entwurf
Ein UFS -Volumen besteht aus den folgenden Teilen:
- Ein paar Blöcke zu Beginn der Partition, die reserviert ist Bootblöcke (die separat vom Dateisystem initialisiert werden muss)
- Ein Superblock mit a magische Zahl Identifizieren Sie dies als UFS -Dateisystem und einige andere wichtige Zahlen, die die Geometrie und die Statistiken und die Verhaltenstunierungsparameter dieses Dateisystems beschreiben
- Eine Sammlung von Zylindergruppen. Jede Zylindergruppe hat die folgenden Komponenten:
- Eine Backup -Kopie des Superblocks
- Ein Zylindergruppenheader mit Statistiken, kostenlosen Listen usw. über diese Zylindergruppe, ähnlich wie im Superblock
- Eine Anzahl von Inoden, jeweils Dateiattribute mit Dateiattributen
- Eine Anzahl von Datenblöcke
Inodes sind nacheinander nummeriert, ab 0. Inode 0 ist für nicht zugewiesene Verzeichniseinträge reserviert. Inode 1 war der Inode der schlechten Blockdatei in historischen Unix -Versionen, gefolgt vom Inode für die Wurzelverzeichnis, was immer Inode 2 und der Inode für das Lost+Found -Verzeichnis, das Inode 3 ist, ist.
Verzeichnisdateien enthalten nur die Liste der Dateinamen im Verzeichnis und den in jeder Datei zugeordneten Inode. Alle Dateien Metadaten werden im Inode gehalten.
Geschichte und Evolution
Frühe Versionen von UNIX -Dateisystemen wurden einfach als bezeichnet Fs. FS enthielt nur den Stiefelblock, Superblock, einen Klumpen von Inodenund die Datenblöcke. Dies funktionierte gut für die kleinen Scheiben, für die frühe Unixe entworfen wurden, aber als die Technologie fortgeschritten war und die Scheiben größer wurden und den Kopf zwischen den Inodes -Klumpen und den von ihnen verwiesenen Datenblöcken hin und her bewegten Prügel. Marshall Kirk McKusick, dann ein Berkeley Doktorand optimierte die BSD 4.2's ffs (schnelles Dateisystem) durch Erfindung von Zylindergruppen, die die Festplatte in kleinere Brocken aufteilen, wobei jede Gruppe ihre eigenen Inodes und Datenblöcke hat.
Die Absicht von BSD FFS besteht darin, zu den zugehörigen Datenblöcken und Metadaten in derselben Zylindergruppe und im Idealfall alle Inhalte eines Verzeichnisses (sowohl Daten als auch Metadaten für alle Dateien) in derselben oder nahe gelegenen Zylindergruppe zu lokalisieren Reduzierung Zersplitterung verursacht durch Streuung des Inhalts eines Verzeichnisses über eine ganze Festplatte.
Einige der Leistungsparameter im Superblock umfassten die Anzahl der Spuren und Sektoren, die Drehzahl, die Kopfgeschwindigkeit und die Ausrichtung der Sektoren zwischen den Spuren. In einem vollständig optimierten System konnte der Kopf zwischen engen Tracks bewegt werden, um verstreute Sektoren von abwechselnden Tracks zu lesen, während die Platte gewartet wird.
Als die Festplatten immer größer wurden, wurde die Optimierung auf Sektorebene veraltet (insbesondere bei Scheiben, die die lineare Sektor-Nummerierung und variable Sektoren pro Spur verwendeten). Bei größeren Scheiben und größeren Dateien wurden fragmentierte Lesevorgänge mehr zu einem Problem. Um dies zu bekämpfen, erhöhte BSD die Größe des Dateisystemblocks ursprünglich von einem Sektor auf 1 K in 4,0 BSD. und erhöhte in FFS die Größe der Dateisystemblockgröße von 1 K auf 8 K. Dies hat mehrere Effekte. Die Wahrscheinlichkeit, dass die Sektoren einer Datei zusammenhängend sind, ist viel größer. Die Menge an Overhead zur Auflistung der Blöcke der Datei wird reduziert, während die Anzahl der Bytes, die durch eine bestimmte Anzahl von Blöcken dargestellt werden können, erhöht werden.
Größere Festplattengrößen sind ebenfalls möglich, da die maximale Anzahl von Blöcken durch eine feste Bit-Breiten-Blocknummer begrenzt ist. Bei größeren Blockgrößen verschwenden die Festplatten mit vielen kleinen Dateien jedoch Platz, da jede Datei mindestens einen Block belegen muss. Aus diesem Grund fügte BSD hinzu Block-Ebene-Fragmentierung, auch genannt Blockieren Sie die Suballokation, Schwanzverschmelzung oder Schwanzverpackung, wobei der letzte Teilblock von Daten aus mehreren Dateien in einem einzigen "Fragment" -Block anstelle von mehreren meist leeren Blöcken gespeichert werden kann.[3]
Implementierungen
Anbieter einiger proprietärer Unix -Systeme, wie z. Sonnenos / Solaris, System V Release 4, HP-UX, und Tru64 UNIXund offene Unix -abgeleitete Systeme wie Illumos, haben UFs übernommen. Die meisten von ihnen adaptierten UFs an ihre eigenen Verwendungen und fügten proprietäre Erweiterungen hinzu, die möglicherweise nicht von den Unix -Versionen anderer Anbieter erkannt werden. Viele[die?] Verwenden Sie weiterhin die ursprünglichen Blockgröße und Datenfeldbreiten als ursprüngliche UFs, sodass ein gewisses Maß an Lesekompatibilität über Plattformen hinweg bleibt.[die?][Nach wem?] Die Kompatibilität zwischen Implementierungen insgesamt ist bestenfalls fleckig.[Nach wem?]
Ab Solaris 7, Sun Microsystems enthalten UFS -Protokollierung, was brachte Dateisystem Journaling zu UFS, die noch in aktuellen Versionen von Solaris und Illumos erhältlich ist.[4] Solaris UFS verfügt auch über Erweiterungen für große Dateien und große Festplatten und andere Funktionen.
In 4.4bsd und BSD Unix -Systeme, die daraus abgeleitet sind, z. Freebsd, Netbsd, OpenBSD, und DragonflybsdDie Implementierung von UFS1 und UFS2 wird in zwei Ebenen aufgeteilt: eine obere Schicht, die die Verzeichnisstruktur bereitstellt und Metadaten (Berechtigungen, Eigentum usw.) in der Inode -Struktur sowie niedrigere Ebenen unterstützt, die als Inodes implementierte Datencontainer bereitstellen. Dies wurde getan, um sowohl die traditionelle FFS als auch die zu unterstützen Lfs Protokolliertes Dateisystem mit gemeinsamem Code für gemeinsame Funktionen. Die obere Schicht heißt "UFS" und die unteren Schichten werden "FFS" und "LFS" bezeichnet. In einigen dieser Systeme wird der Begriff "FFS" für die Kombination der unteren Schicht der FFS und der UFS -oberen Schicht verwendet, und der Begriff "LFS" wird für die Kombination der unteren LFS und der oberen Schicht UFS verwendet.
Kirk McKusick implementierte die Umverteilung der Block, eine Technik, die die Blöcke im Dateisystem vorbestimmt, kurz bevor die Schreibvorgänge abgehalten werden, um die Alterung von Fragmentierungs- und Steuerungsdateisystemen zu verringern. Er hat auch implementiert weiche Updates, ein Mechanismus, der die Konsistenz des Dateisystems beibehält, ohne die Leistung so zu begrenzen, wie der herkömmliche Synchronisierungsmodus dies getan hat. Dies hat den Nebeneffekt, die Anforderung der Überprüfung des Dateisystems nach einem Absturz oder Stromausfall zu verringern. Um die verbleibenden Probleme nach einem Fehler zu überwinden, wurde ein Hintergrund -FSCK -Dienstprogramm eingeführt.
In UFS2, Kirk McKusick und Poul-Henning Kamp Erweiterten die FreeBSD-FFS- und UFS Zebibyten), Blöcke in variabler Größe (ähnlich wie Ausdehnung), erweiterte Flaggenfelder, zusätzliche Stempel von "Geburtszeit", erweiterte Attributunterstützung und posix1.e ACLs. UFS2 wurde zur Standard -UFS -Version, beginnend mit FreeBSD 5.0. FreeBSD führte auch Soft -Updates und die Möglichkeit ein, Dateisysteme zu erstellen Schnappschüsse für UFS1 und UFS2. Diese wurden seitdem auf NetBSD portiert, aber schließlich wurden sanfte Updates (so genannte Softendien in NetBSD) aus NetBSD 6.0 zugunsten des weniger komplexen Dateisystems Journaling -Mechanismus genannt WAPBL (auch als Protokollierung bezeichnet), das FFS in NetBSD 5.0 hinzugefügt wurde. OpenBSD hat seit Version 2.9 Soft -Updates unterstützt[5] und hatte seit Version 4.2 UFS2 (FFS2) -Aushilfe (keine ACLs).[6] OpenBSD hat jetzt UFS2 zur Standard -UFS -Version gemacht und wird in der 6.7 -Version enthalten.[7] Seit FreeBSD 7.0 unterstützt UFS auch Dateisystem Journaling Verwenden des Gjournal Geom Anbieter. FreeBSD 9.0 unterstützt leichte Journaling auf Soft Updates (SU+J), was den Bedarf an Hintergrund -FSCK und NFSV4 -ACLs erheblich reduziert.
FreeBSD, NetBSD, OpenBSD und Dragonfly BSD enthalten auch die Dirhash System, entwickelt von Ian Dowse. Dieses System behält eine In-Memory-Hash-Tabelle bei, um das Verzeichnis-Lookups zu beschleunigen. Dirhash lindert eine Reihe von Leistungsproblemen im Zusammenhang mit großen Verzeichnissen in UFs.
Linux Beinhaltet eine UFS -Implementierung für binäre Kompatibilität auf der Leseebene mit anderen Unixe. Da jedoch keine Standardimplementierung für die Anbieter -Erweiterungen zu UFS vorhanden ist, bietet Linux keine vollständige Unterstützung für das Schreiben an UFS. Der native Linux ext2 Das Dateisystem wurde von UFS1 inspiriert, unterstützt jedoch keine Fragmente und es gibt keine Pläne, Soft Updates zu implementieren. (In einigen 4,4BSD-abgeleiteten Systemen kann die UFS-Ebene eine ext2-Ebene als Containerschicht verwenden, wie sie FFS und LFS verwenden kann.)
Nächster Schritt, was von BSD abgeleitet wurde, verwendete auch eine Version von UFs. Im Apfel's Mac OS X, es war als Alternative zu erhältlich HFS+, ihr proprietäres Dateisystem. Jedoch nach Mac OS X LeopardEs war nicht mehr möglich, Mac OS X auf einem UFS-formatierten Volumen zu installieren. Darüber hinaus kann man ältere Versionen von Mac OS X nicht aktualisieren, die auf UFS-formatiertem Volumen auf Leopard installiert sind. Das Upgrade erfordert die Neuformatierung des Startaufs.[8] Es gab eine 4 -GB -Dateilimit für Festplatten, die in Mac OS X als UFS formatiert wurden. Abs Mac OS X LöweDie UFS -Unterstützung wurde vollständig fallen gelassen.[9]
Siehe auch
Verweise
Zitate
- ^ a b c "[Basis] Inhalt von /head/sys/ufs/ufs/dinode.h".
- ^ "Dateisysteme Howto: Andere Dateisysteme".
- ^ Allen, Hervey (2005-06-20). "UFS2 und Soft Updates sorgen für eine leistungsstarke Kombination" (PDF). Einführung in FreeBSD, Pacnog I Workshop, zusätzliche Themen. Netzwerkstart -Ressourcenzentrum. p. 23. Abgerufen 2013-04-08.
- ^ http://docs.oracle.com/cd/e19253-01/817-5093/fsoverview-43/index.html
- ^ "OpenBSD 2.9 Release". OpenBSD. 2001-06-01. Abgerufen 2013-04-08.
- ^ "OpenBSD 4.2 Release". OpenBSD. 2007-11-01. Abgerufen 2013-04-08.
- ^ "Machen Sie FFS2 zum Standard -Dateisystem". OpenBSD. 2020-04-05. Abgerufen 2020-04-07.
- ^ "Archiviert-Mac OS X 10.5 Leopard: Installation auf einem UFS-formatierten Volumen". Apple Inc. 2012-06-12. Abgerufen 2013-04-08.
- ^ "Löwe montiert keine Festplattenbilder mit dem integrierten Dienstprogramm oder dem Dienstprogramm für Festplatten". Apple Support Communities. Apple Inc. 2011-08-05. Abgerufen 2013-12-24.
Literaturverzeichnis
- Marshall Kirk McKusick, William N. JoySamuel J. Leffler und Robert S. Fabry. Ein schnelles Dateisystem für UNIX (PDF) (Technischer Bericht). Forschungsgruppe für Computersysteme, Abteilung für Informatik, Abteilung für Elektrotechnik und Informatik, Universität von Kalifornien, Berkeley. Abgerufen 2013-04-08.
{{}}
: Cs1 montiert: Mehrfachnamen: Autorenliste (Link) - Marshall Kirk McKusick, William N. Joy, Samuel J. Leffler und Robert S. Fabry (August 1984). "Ein schnelles Dateisystem für Unix" (PDF). ACM -Transaktionen auf Computersystemen. 2 (3): 181–197. doi:10.1145/989.990. S2CID 222285164. Abgerufen 2013-04-08.
{{}}
: Cs1 montiert: Mehrfachnamen: Autorenliste (Link) - Marshall Kirk McKusick; Keith Bostic; Michael J. Karels & John S. Quarterman (1996). "Lokale Dateisysteme; lokale Filestores". Das Design und die Implementierung des 4.4BSD -Betriebssystems. Addison-Wesley. ISBN 0-201-54979-4.
- Marshall Kirk McKusick & Gregory R. Ganger (Juni 1999). "Soft Updates: Eine Technik zur Beseitigung der meisten synchronen Schreibvorgänge im schnellen Dateisystem" (PDF). Proceedings of the Freenix Track: 1999 Usenix jährliche technische Konferenz. S. 1–18. Abgerufen 2013-04-08.
- Marshall Kirk McKusick (Februar 2002). "FSCK" im Hintergrund "ausführen". Verfahren des BSDCon 2002. S. 55–64. Abgerufen 2013-04-08.
- Marshall Kirk McKusick (September 2003). "Verbesserungen des schnellen Dateisystems zur Unterstützung von Multi-Terrass-Speichersystemen". Verfahren des BSDCON 2003. Abgerufen 2019-02-07.
- Richard McDougall;Jim Mauro (2006)."15: Das UFS -Dateisystem". Solaris Interna: Solaris 10 und OpenSolaris Kernel Architektur (PDF) (2 ed.). ISBN 0-13-148209-2.
Externe Links
- Jeroen C. Van Gelderen (2003-04-23). "Little UFS2 FAQ". Freebsd. Abgerufen 2013-04-08.
- "Dateisysteme Howto: Andere Dateisysteme". Das Linux -Dokumentationsprojekt.2007-01-27.
- Das Solaris UFS -Dateisystem, siehe auch [1]
- USF (SIC)/UFS2 -Format
- Lokalität und das schnelle Dateisystem