Für jeden Anwendungsfall gibt es heute ein optimiertes Dateisystem. Allen gemeinsam ist die Anforderung, die Verzeichnisse sehr schnell zu durchsuchen, um auf die Blöcke der Dateien auf den Datenträgern zugreifen zu können. Für die Einhaltung dieser Anforderung werden so genannte B- oder B+-Bäume für die Organisation des Verzeichnisses verwendet, das dem Inhaltsverzeichnis eines Buches entspricht.
Grundlegend wird nach block- und dateibasierten Speichersystemen differenziert. Auf Ersteren wird mittels eines "Formats" ein Dateisystem angelegt und dann diesem Speicherbereich entweder ein Laufwerksbuchstabe zugewiesen (wie bei Windows), oder er wird per "mount" in ein vorhandenes Verzeichnis eingehängt.
Lokale Festplatten, optische Medien (CD-ROM, DVD, BD), SAN- und iSCSI-Speicher bedient das Betriebssystem direkt; die Blöcke darauf werden linear adressiert. Zu den lokalen Speichermedien kann man in der Regel diejenigen zählen, die im Servergehäuse oder in unmittelbarer Nähe platziert und über die Schnittstellen IDE, ATA, SATA, SCSI, SAS, USB oder IEEE1394 angebunden sind.
Zu den bekannten blockbasierten Dateisystemen zählen beispielsweise:
-
File Allocation Table FAT (FAT12, FAT16, FAT32, exFAT, VFAT)
-
New Technologie Filesystem NTFS (v4, v5)
-
Extended Filesystem ext (ext2, ext3, ext4)
-
B+-Tree Filesystem (BTRFS)
-
REISERFS
-
MINIX
-
MSDOS
-
HPFS [OS/2; IBM]
-
XFS
-
JFS/ JFS2 [IBM]
-
UNIX Filesystem (UFS)
-
HFS/ HFS+ [Apple]
-
ZFS [SUN/ ORACLE]
Bei den optischen Medien haben sich seit dem High-Sierra-Format im Wesentlichen zwei Dateisysteme etabliert: das ISO9660 als internationaler Nachfolger und das Universal-Disk-Format (UDF). Erweiterungen wie Rockridge und Joliet sowie überarbeitete Versionen stellen zum einen Kompatibilität zwischen den verschiedenen Betriebssystemen sicher, zum anderen erlauben sie beispielsweise längere Dateinamen oder geänderte Zeichenkodierungen.
Netzwerkdateisysteme
Im Gegensatz zu den lokalen Speichercontainern stellen die Netzwerkdateisysteme den Zugriff auf Dateien über definierte Protokolle sicher. Klassische Client- und Server-Konstellationen funktionieren so, dass der Client über ein Netzwerk ein entferntes Dateisystem lokal einbindet.
Bei der typischen Anwendung greifen viele Clients auf einen Dateiserver zu. Die Performance wird durch die Leistung des Servers und die Netzwerkanbindung bestimmt. Die Zugriffsteuerung auf gleiche Dateien ist durch nur eine Kontrollinstanz - hier: der Dateiserver - trivial.
Zu den verbreiteten Netzwerkdateisystemen zählen:
-
SUN/ ORACLE Network Filesystem (NFS)
-
Server Message Block (SMB), Common-Internet Filesystem (CIFS)
-
Apple Filer Protocol (AFP)
-
xFS (University of Berkeley)
-
CODA (Carnegie Mellon University)
-
Andrew Filesystem (AFS)
Geht es um Skalierbarkeit, Leistungssteigerung und Zuverlässigkeit, kommen verteilte oder Cluster-Dateisysteme zum Einsatz. Vom Grundprinzip her wird der Namensraum auf je einen Dateiserver (Cluster-Member) aufgeteilt. Dadurch verteilt sich die Auslastung über das Dateisystem gleichmäßig. Die Herausforderung liegt nun darin, dass zum einen die Zugriffssteuerung effektiv und effizient funktionieren und zum anderen jeder Clusterknoten über Änderungen informiert werden muss, um die Dateisystemkonsistenz zu gewährleisten.
Typische Vertreter von Cluster-Dateisystemen sind:
-
Global Filesystem GFS
-
Oracle Cluster-Filesystem Version 2 (OCFS2)
-
IBRIX
In Alltag braucht man sich kaum Gedanken über dessen Auswahl zu machen. Mobile, optische und magnetische Datenträger für Windows- und Linux-Betriebssysteme oder Unix-Derivate haben etablierte Formate, mit denen man im Alltag gut über die Runden kommt.
Zu den sogenannten virtuellen Dateisystemen zählen beispielsweise unter Unix/ Linux "tmpfs", "proc" "sysfs", "debugfs" und "cgroup". Diese allozieren keinen physikalischen Disk-Platz und dienen lediglich dem Zugriff auf Kernel-Ressourcen über die I/O-Systemaufrufe.
Zugriff
Wie aber kommen nun die Datenblöcke vom Speichermedium zur Applikation? Bevor eine Applikation die vom Benutzer angeforderten Daten vom Speichersystem im Hauptspeicher nutzen kann, muss das Betriebssystem (Kernel) über definierte Schnittstellen diese Daten anfordern. Der Treiber für die Hardware liefert Datenblöcke meist in Dimensionen von 512 Byte oder 4 KByte, die Applikation weiß aber im Gegenzug nicht, wie das Layout auf dem Speichersystem aussieht. Diese Schnittstelle füllt das Virtual-File-System (VFS), das als Verteilzentrum im Kernel fungiert. Damit wird jeder Dateisystemzugriff transparent für den Prozess über die wesentlichen Dateisystemfunktionen open(), read(), write() und close() ausgeführt. Über die FUSE-Schnittstelle (Filesystem in Userspace) können auch Dateisysteme im Userland über VFS eingehängt werden.
Blockbasierte Dateisysteme liefern ein hierarchisches Verzeichnis über die gespeicherten Dateien und offerieren damit gleichzeitig den objektbasierten Zugriff darauf mittels Namen. Über die referenzierte Suche in diesem Verzeichnis werden die zu einer Datei gehörigen Datenblöcke ermittelt und gelesen. Neben den Nutzdatenblöcken stehen in den dazugehörigen Metadatenblöcken weitere Informationen zur Verwaltung. Unter Unix/Linux werden diese Metadaten im sogenannten eindeutigen I-Node hinterlegt; unter Windows NTFS entsprechend in den File Records.
Den objektbasierten Zugriff bieten mittlerweile auch entsprechende Speichersysteme, die sogenannten "Object-based Storage Devices" (OSD). Mit "Lustre" gibt es einen Vertreter der objektbasierten Dateisysteme.
Caching
Wesentliche Meta- und Verwaltungsdaten eines Dateisystems werden meistens im sogenannten Zwischenspeicher (Buffer-Cache) des Hauptspeichers vorgehalten und dann in Zeitintervallen en bloc gesichert. Damit wird sichergestellt, dass man nicht so oft auf den langsamen Speicher zugreifen muss.
Viele Unix-/Linux-Dateisysteme und auch das HFS+-Dateisystem unterstützen einen direkten Zugriff ohne Caching. Ist normalerweise der Modus "async" aktiv, wird im anderen Fall der schreibende Applikationsprozess erst dann über einen erfolgreichen Schreibvorgang informiert, wenn wirklich die Blöcke auf dem Medium gelandet sind (Festplatten-Caches einmal ausgenommen). Dies ist beispielsweise dann sinnvoll, wenn die Applikation bereits Datenblöcke im Speicher vorhält.
Bei Netzwerkdateisystemen speichert meist auch der Client noch lokal Daten zwischen, um den Netzwerkverkehr von kleinen Paketen zu entlasten.
Logging-/Journaling-Dateisysteme
Was heißt Logging- oder Journaling-Eigenschaft bei den Dateisystemen? Ursache für dessen Einführung ist, dass die Speichersysteme immer größer wurden und damit auch zwangsläufig ein Dateisystem-Check (fsck, chkdsk) mehr Metadaten verarbeiten muss, was Zeit kostet. Bei aktuellen Dimensionen ist eine Wartezeit von mehreren Stunden nicht mehr akzeptabel. Von daher nutzt man heute besser den folgenden Workflow dafür:
-
Ziel: Block 3 und 25 von Datei schreiben
-
Schreibe ins Journal: "Schreibe Block 3", "Schreibe Block 25", Kopiere: Block 3 und 25 ins Journal
-
Schreibe: Block 3 und Block 25
-
Schreibe ein "COMMIT" für die Ausführung ins Journal
-
Ziel erreicht: Block 3 und 25 auf Medium geschrieben
Ist nach dem Booten des Systems der "COMMIT" Eintrag im Journal nicht vorhanden, so heißt dies, dass die Blöcke noch nicht auf dem Medium gelandet sind und somit diese Aktion nun nachgeholt werden muss. Damit wäre das Dateisystem wieder konsistent. Wohlgemerkt: Hhier geht es um die Konsistenz des Dateisystems, nicht der Absicherung der unverfälschten Datenblöcke.
Klassiker im Linux-Bereich mit Journaling ist das ext3-Dateisystem, das ext2 um eine Journaling-Funktion erweitert. Dessen aktueller Nachfolger ext4 soll nun besser skalieren. Microsoft hat sein New Technologie File System (NTFS) seit Einführung von Windows NT ebenfalls mehrfach überarbeitet. Log-Einträge des Journals landen in der Datei "$LogFile". Neben dem NTFS-Log-Journal gibt es auch das Update-Sequence-Number (USN)-Journal, das Änderungen an Dateien, Verzeichnissen und Streams aufzeichnet und somit Audit-Informationen liefern kann. Apples HFS+ als Nachfolger von HFS unterstützt ebenfalls die Journaling-Funktion.
Ein wenig ungewöhnlich ist bei NTFS die Tatsache, dass die Metadaten ebenfalls als "normale" Dateien im Dateisystem abgelegt sind, aber von Windows für den Anwender ausgeblendet werden. Die wichtigste Datei im Hauptverzeichnis ist die Master-File-Table (MFT$). Daneben kommen beispielsweise noch "$badclus" für fehlerhafte Cluster und "$Extend" für die Extents zur Anwendung.
Herausforderungen
Reichten vor einiger Zeit noch Dateinamen im Format 8.3 aus, so können inzwischen längst Dateinamen bis zu 255 Zeichen lang werden. Problematisch sind reservierte dateisystemtypische-Zeichen, beispielsweise ".", "..", "/", "\", ":", "*", "?", doppelte Anführungszeichen sowie "<", ">" und "|".
Je nach Dateisystem werden Zeichen oder ganze Dateinamen besonders behandelt. Der führende Punkt im Namen ".test" sorgt beim Unix-/Linux-Kommando "ls" dafür, dass dieser Verzeichniseintrag nicht angezeigt wird. Dies ist aber eine Eigenheit von "ls" und nicht des Dateisystems. Attribute wie "hidden" und "system" werden noch oft in den Metadaten abgelegt.
Zugriffssperren
Im Gegensatz zu Windows-Betriebssystemen, die den Zugriff auf eine geöffnete Datei anderen Prozessen komplett verweigern (Lese- und Schreibsperre), erlauben Unix-/Linux-basierte Systeme in der Regel bei einem Exclusive-Lock einen Lesezugriff (exclusive lock wird auch write-lock genannt), obwohl mit dem Shared-Lock natürlich auch eine Lesesperre möglich ist. Jeder Prozess kann eine Lese-, aber nur ein Prozess eine Schreibsperre aktivieren.
Programmierer werden den POSIX-Systemaufruf "lockf()" oder den unter Linux verwendeten NON-POSIX-Aufruf "fcntl()" sicherlich kennen. Damit lassen sich Segmente oder die komplette Datei in verschiedenen Modi für andere Prozesse unter anderem sperren.
Grundsätzlich werden zwei Typen von Lockmechanismen unterschieden, nämlich die verbindlichen (a) und die freiwilligen (b). Variante (a) sind die Mandatory-Locks auf Dateien. Sobald ein Prozess einen Lock gesetzt hat, wird jeder andere Prozess, der einen Zugriff auf diese (offene) Datei erwirken möchte, so lange blockiert, bis der Lock wieder aufgehoben wird. Das Dateisystem muss diese Art unterstützen, das heißt die mount-Option "mand" beziehungsweise das Flag "MS_MANDLOCK" interpretieren.
Die andere Variante (b), die Advisory-/Mutual-Locks, kommt dann zum Einsatz, wenn sich kooperierende Prozesse den Zugriff auf eine Datei koordiniert teilen möchten. Dann versucht der eine Prozess einen Schreiblock auf die ersten 100 Byte zu bekommen und erhält diesen als Erster. Ein weiterer Prozess sperrt das letzte Kilobyte an Date, und Prozess drei versucht ebenfalls die ersten 100 Byte zu sperren; der Lock ist bereits aktiv, und so wird der Prozess suspendiert, bis der erste Prozess den Lock aufgehoben hat. Anschließend kann dieser dann mit der Ausführung fortfahren.
Würden die anderen Prozesse nicht ebenfalls diesen Lock-Mechanismus nutzen, würden die Daten wild durcheinandergeschrieben. Anstelle den Prozess zu blockieren, kann dieser natürlich auch versuchen, einen weiteren Teilbereich der Datei zu bearbeiten, während der andere Lock aktiv ist. Somit können multithreaded agierende Applikationen die Ressourcen besser ausnutzen.
Access Control Lists (ACL)
Die POSIX Access Control Lists ermöglichen eine feiner granulierte Zugriffssteuerung, als es die Gruppen- und Benutzerrechte einer Datei erlauben würden. NTFS und HFS+ nutzen diese standardmäßig, bei Linux mit einer ext-Ausführung muss die Mount-Option "acl" aktiviert werden. Anschließend können mittels der acl-Tools "getfacl", "setfacl" und "chacl" die Zugriffsrechte verwaltet werden.
Problembehandlung
Sollte der Kernel Inkonsistenzen im Dateisystem feststellen, so gibt es bei Linux und entsprechenden Dateisystemen drei Möglichkeiten, dem Kernel beim mount()-Aufruf mitzuteilen, wie die Reaktion darauf aussehen soll:
-
continue
-
remount-ro
-
panic
Bei "continue" ignoriert der Kernel den Fehler, markiert das Dateisystem aber als fehlerbehaftet. Im zweiten Fall wird das Dateisystem read-only gesetzt, und die dritte Möglichkeit besteht darin, dass der Kernel einen Panic generiert und in den Halt()-Modus geht. Dieser Modus ist im Dateisystem-Superblock hinterlegt und kann auch dort modifiziert werden (tuneXfs).
Aliase, Junctions und Verknüpfungen
Oft ist es erforderlich, eine Datei unter einem anderen Namen anzusprechen, obwohl die Daten identisch sind und Modifikationen dennoch für jeden Dateinamen wirksam werden sollen. Eine Kopie würde physikalischen Platz beanspruchen und eine Änderung der Daten nicht mitbekommen.
Hier kommen sowohl Hard- als auch Softlinks zur sinnvollen Anwendung. Diese kopieren lediglich die Verzeichnismetadaten unter einem anderen Namen mit Verweis auf die Datenblöcke. Funktionieren Hardlinks nur im gleichen Dateisystem, bieten Softlinks zusätzlich die Möglichkeit, auf Verzeichnisse zu verlinken. Linux- und Unix-Derivate machen regen Gebrauch davon. Apples OS X als BSD-Variante kennt darüber hinaus seit Mac OS System 7 beim HFS- und HFS-Plus Filesystem darüber hinaus die sogenannten Aliase - eine dynamische Referenz zu einem Objekt. Sie bieten die Funktionalität der Softlinks und passen auch den Alias an, wenn sich das Ziel im gleichen Dateisystem verändert (Name, Ort, Größe). Diese erwünschte Funktion kann aber auch zu Irritationen führen, wenn ein Alias (über das Dock) angesprochen wird und die Applikation (Alias-Ziel) in den Papierkorb verschoben wurde, aber immer noch gleich gestartet wird. Mac-OS-Aliase können darüber hinaus auch auf entfernte Netzwerk-Shares verweisen.
Unter Windows mit NTFS entspricht der Alias in etwa den Verknüpfungen (Endung .lnk) auf Verzeichnisse oder Dateien, allerdings wird diese ungültig, sobald das Verweisziel verschoben wurde. NTFS bietet mit den "Junctions" eine praktikablere Lösung der Verweise auf Verzeichnisse, die auch im Windows Explorer und im Command-Prompt das Ziel adressiert. Zu den Tools für Junctions - die auch eine Art NTFS reparse points sind - zählen "fsutil", "linkd" oder "mklink", je nach Windows-Version. Aus den Winternals gibt es das Tool "junction". Elementare Windows-Programme sollen aber in der Vergangenheit auch rekursiv das Ziel anstelle des Junction-Eintrags gelöscht haben. Hardlinks sind ähnlich wie die Junctions, verweisen aber ausschließlich auf Dateien im gleichen Dateisystem. OS/2 bildete die Alias-Funktion mit "Shadows" ab.
|
Eigenschaft/Version |
Win NT 3.1 |
Win NT 3.5 |
Win NT 3.51/ 4 |
Win 2K/ Win NT 5.0 |
Win XP Server 2003 Win NT 5.1 |
Vista,7 Server 2008 Win NT 6.0 |
|
NTFS-Version |
1.0 |
1.1 |
1.2 |
3.0 |
3.1 |
|
|
"junctions"-Tool |
- |
- |
- |
linkd |
fsutil |
mklink |
|
Alternate Data Streams (ADS) |
x |
x |
ok |
<-- |
<-- |
<-- |
|
NTFS ACLs |
x |
x |
ok |
<-- |
<-- |
<-- |
|
Transparente Kompression |
x |
x |
LZ77 |
<-- |
<-- |
<-- |
|
Transparente Verschlüsselung |
x |
x |
x |
DESX AES |
+Triple DES |
|
|
Disk Quotas |
x |
x |
x |
ok |
<-- |
<-- |
|
Sparse Files |
x |
x |
x |
ok |
<-- |
<-- |
|
Symbolische Links |
x |
x |
x |
x |
x |
ok |
|
Transactional NTFS |
x |
x |
x |
x |
x |
ok |
NTFS bietet die nachfolgenden Datei- und Verzeichnisattribute: read-only, hidden, system, archive, not content indexed, off-line, temporary und compressed.
Resource-Forks und Datenstreams
Besteht ein einfacher Verzeichniseintrag für eine Datei aus deren Namen, den Metadaten und einem Verweis auf die Datenblöcke, so bieten HFS/HFS+ und NTFS noch weitere Datenströme für spezifische Anwendungen. Bei NTFS spricht man von Advanced Data Streams (ADS) und bei HFS+ von den Resource-Forks, also den weiteren Abzweigungen neben dem eigentlichen Datenstrom (Data-Fork).
Hauseigene NTFS-Kopierwerkzeuge kopieren aber scheinbar nur den Datenstrom, also die eigentlichen Datenblöcke ohne weitere Streams. HFS+ speichert beispielsweise dort unstrukturierte weitere Dateieigenschaften, wie unterschiedliche Icon-Größen, Aliase oder Applikationszuweisungen. Wird eine Datei aus dem HFS+-Dateisystem auf ein anderes Dateisystemformat kopiert, gehen die Resource-Forks in der Regel verloren.
Groß- und Kleinschreibung
Beim Datenaustausch mit anderen Betriebssystemen ist es nicht unerheblich, ob ein Dateisystem Case-sensitive und/oder Case-preserving ist. Schließlich wird eine Datei mit Namen "Test" ansonsten nicht gefunden, wenn diese als "test" abgelegt wurde. Case-preserving ist ein Dateisystem dann, wenn "TEst" als "TEst" und "test" als "test" abgespeichert wird, aber "TEst" und "test" genau die gleiche Datei adressieren, die somit nur einmal im gleichen Verzeichnis existieren darf. Somit kann diese Datei als "TEst", aber auch in allen Variationen und im einfachsten Fall mittels "test" angesprochen werden.
|
Dateisystem |
POSIX ACLs |
Quota |
Fehler- reaktion |
Journaling |
Case-Sensitiv |
Case-Preserving |
Forks/ ADS |
B+ Baum Verzeichnis |
Online Komprimierung |
Online Verschlüsselung |
|
ext2 |
ok |
ok |
ok |
x |
ok |
ok |
x |
x |
x |
x |
|
ext3, ext4 |
ok |
ok |
ok |
ok |
ok |
ok |
x |
ok |
x |
x |
|
HFS+ |
ok |
ok |
- |
ok |
ok |
ok |
ok |
ok |
ok, seit 10.6 |
x |
|
jfs/ jfs2 |
- |
ok |
ok |
ok |
ok |
ok |
X |
ok |
x |
x |
|
NTFS |
ok |
ok |
x |
ok |
x |
x |
ok |
ok |
ok |
ok |
Quota und Sparse-Dateien
Greifen mehrere Benutzer auf das gleiche Dateisystem zu, ist es oft wünschenswert, die Anzahl der Dateien oder die gesamte Speicherplatznutzung zu begrenzen. Hier kommen die Benutzer- und Gruppen-Quota zur Anwendung.
Unter NTFS muss diese Überwachung erst gestartet werden. Bei den anderen Dateisystemen werden die Optionen "usrquota" oder "grpquota" des mount-Aufrufs verwendet. Ein Softquota-Limit kann für eine definierte Zeit überschritten werden. Ein Hardquota-Wert begrenzt die Ressource endgültig.
Unter den inodebasierten Dateisystemen können Dateien angelegt werden, die aus einer großen Anzahl an Nullen und wenigen anderen Daten bestehen. Beansprucht eine solche Datei beispielsweise 1 GByte, würde sie nicht besonders vom Dateisystem behandelt und als Sparse-Datei markiert werden. Logische und physische Dateigröße weichen also voneinander ab. NTFS ab Version 3 und viele Unix-/Linux-Dateisysteme unterstützen diese Form der Dateiablage.
Spezielle Dateisysteme
Zu den speziellen Dateisystemen zählen wir beispielsweise:
-
Write-Anywhere-Filesystem-Layout WAFL von Netapp (im eigentlichen Sinn kein Dateisystem)
-
Linear Tape Filesystem LTFS für Bandlaufwerke seit 2010
Features wie Online-Verschlüsselung, Komprimierung, Snapshots oder Online-Verkleinerung bieten aktuell nur NTFS und ZFS zuverlässig. Copy-on-Write (COW) ist eine Technik, die schnell Dateien vervielfältigen kann, indem lediglich Referenzen auf die Datenblöcke angelegt werden. Erst wenn Blöcke verändert werden, werden auch die Kopien gesichert. So spart man beispielsweise bei Snapshots Zeit und Speicherplatz.
Mit ZFS hat Sun Microsystems (heute Oracle) ein mit 128-Bit-Zeigern funktionierendes COW-Dateisystem auf den Markt gebracht, das auch die Funktion eines Volume-Managers übernimmt. Zusätzlich bietet es Deduplizierung, Komprimierung sowie Verschlüsselung und sichert seine Blöcke mit einer Prüfsumme.
WAFL von der Firma Netapp verwaltet RAID-Arrays effizient und erlaubt eine schnelle Dateisystemvergrößerung. Dabei benötigt WAFL nur eine geringe Zeit für den Dateisystemkonsistenz-Check beim Neustart und bietet Deduplizierung auf Blockebene. Daneben unterstützt es parallel Unix-Zugriffsrechte und NTFS ACLs.
Fazit
Das universelle Dateisystem für jeden Anwendungsfall existiert nicht. Dennoch haben die meisten ihre Daseinsberechtigung, denn passend eingesetzt können sie ihre Stärken auch zeigen.
Verteilte und Cluster-Dateisysteme mit gleichzeitigem Zugriff aller Knoten auf die gleichen Daten haben immer einen Administrations-Overhead für den Lock-Mechanismus. Neben Caching und dem Einsatz von schnellen Suchbäumen scheinen die Möglichkeiten für weitere Optimierungen begrenzt zu sein.
Etabliert sich ZFS nach UFS und XFS im Unix- und BTRFS nach ext4 im Linux-Bereich, gibt es für NTFS und HFS+ aktuell keine Neuigkeiten. (cvi)