Dateisystem-API - File system API

Eine Dateisystem- API ist eine Anwendungsprogrammierschnittstelle, über die ein Dienstprogramm oder Benutzerprogramm Dienste eines Dateisystems anfordert. Ein Betriebssystem kann Abstraktionen für den transparenten Zugriff auf verschiedene Dateisysteme bereitstellen.

Einige Dateisystem-APIs können auch Schnittstellen für Wartungsvorgänge enthalten, z. B. das Erstellen oder Initialisieren eines Dateisystems, das Überprüfen des Dateisystems auf Integrität und die Defragmentierung .

Jedes Betriebssystem enthält die APIs, die für die unterstützten Dateisysteme erforderlich sind. Microsoft Windows verfügt über Dateisystem-APIs für NTFS und mehrere FAT- Dateisysteme. Linux- Systeme können APIs für ext2 , ext3 , ReiserFS und Btrfs enthalten, um nur einige zu nennen.

Geschichte

Einige frühe Betriebssysteme waren nur in der Lage, Band- und Festplattendateisysteme zu verarbeiten . Diese stellten die grundlegendsten Schnittstellen bereit mit:

  • Schreiben, lesen und positionieren

Für eine bessere Koordination wie Gerätezuweisung und Freigabe mussten Folgendes hinzugefügt werden:

  • Offen und geschlossen

Da Dateisysteme mehr Dienste bereitstellten, wurden mehr Schnittstellen definiert:

  • Metadatenverwaltung
  • Wartung des Dateisystems

Da zusätzliche Dateisystemtypen, Hierarchiestrukturen und unterstützte Medien zunahmen, erforderten zusätzliche Funktionen einige spezielle Funktionen:

Für Mehrbenutzersysteme sind APIs erforderlich für:

  • Teilen
  • Zugriff einschränken
  • Verschlüsselung

API-Übersichten

Schreiben, lesen und positionieren

Das Schreiben von Benutzerdaten in ein Dateisystem wird zur direkten Verwendung durch das Benutzerprogramm oder die Laufzeitbibliothek bereitgestellt. Die Laufzeitbibliothek für einige Programmiersprachen bietet möglicherweise Typkonvertierung, Formatierung und Blockierung. Einige Dateisysteme ermöglichen die Identifizierung von Datensätzen anhand von Schlüsseln und können das Umschreiben eines vorhandenen Datensatzes umfassen. Diese Operation wird manchmal aufgerufen PUToder PUTX(wenn der Datensatz vorhanden ist)

Das Lesen von Benutzerdaten, manchmal auch als GET bezeichnet , kann eine Richtung (vorwärts oder rückwärts) oder im Fall eines verschlüsselten Dateisystems einen bestimmten Schlüssel enthalten. Wie beim Schreiben können Laufzeitbibliotheken für das Anwenderprogramm intervenieren.

Die Positionierung umfasst das Anpassen der Position des nächsten Datensatzes. Dies kann das Überspringen vorwärts oder rückwärts sowie das Positionieren am Anfang oder Ende der Datei umfassen.

Offen und geschlossen

Die offene API kann explizit angefordert oder implizit aufgerufen werden, wenn die erste Operation von einem Prozess für ein Objekt ausgegeben wird. Dies kann dazu führen, dass Wechselmedien bereitgestellt werden, eine Verbindung zu einem anderen Host hergestellt und der Speicherort und die Zugänglichkeit des Objekts überprüft werden. Es aktualisiert Systemstrukturen, um anzuzeigen, dass das Objekt verwendet wird.

Zu den üblichen Anforderungen für die Anforderung des Zugriffs auf ein Dateisystemobjekt gehören:

  1. Das Objekt, auf das zugegriffen werden soll (Datei, Verzeichnis, Medium und Speicherort)
  2. Die beabsichtigte Art von Operationen, die nach dem Öffnen ausgeführt werden sollen (Lesen, Aktualisieren, Löschen)

Beispielsweise können zusätzliche Informationen erforderlich sein

  • ein Passwort
  • eine Erklärung, dass andere Prozesse auf dasselbe Objekt zugreifen können, während der Öffnungsprozess das Objekt verwendet (Freigabe). Dies kann von der Absicht des anderen Prozesses abhängen. Im Gegensatz dazu eine Erklärung, dass kein anderer Prozess auf das Objekt zugreifen darf, unabhängig von der Absicht des anderen Prozesses (ausschließliche Verwendung).

Diese werden über eine Programmiersprachenbibliothek angefordert, die zusätzlich zur Weiterleitung der Anforderung an das Dateisystem eine Koordination zwischen den Modulen im Prozess bereitstellen kann.

Es ist zu erwarten, dass bei der Verarbeitung des Open etwas schief gehen kann.

  1. Das Objekt oder die Absicht kann falsch angegeben werden (der Name kann ein nicht akzeptables Zeichen enthalten oder die Absicht wird nicht erkannt).
  2. Der Prozess kann möglicherweise nicht auf das Objekt zugreifen (möglicherweise nur für eine Gruppe oder einen bestimmten Benutzer).
  3. Das Dateisystem kann möglicherweise keine Strukturen erstellen oder aktualisieren, die zur Koordinierung der Aktivitäten zwischen Benutzern erforderlich sind.
  4. Im Fall eines neuen (oder Ersatz-) Objekts ist möglicherweise nicht genügend Kapazität auf dem Medium vorhanden.

Abhängig von der Programmiersprache können zusätzliche Spezifikationen im Freien die Module für diese Bedingungen festlegen. Einige Bibliotheken geben dem Dateisystem ein Bibliotheksmodul an, das eine Analyse ermöglicht, falls das Eröffnungsprogramm aufgrund eines Fehlers keine sinnvolle Aktion ausführen kann. Wenn der Fehler beispielsweise beim Versuch liegt, die erforderliche Eingabedatei zu öffnen, besteht die einzige Aktion möglicherweise darin, den Fehler zu melden und das Programm abzubrechen. Einige Sprachen geben einfach einen Code zurück, der die Art des Fehlers angibt, der immer vom Programm überprüft werden muss. Dieser entscheidet, was gemeldet werden soll und ob er fortgesetzt werden kann.

Das Schließen kann dazu führen, dass Wechselmedien entfernt oder ausgeworfen werden und Bibliotheks- und Dateisystemstrukturen aktualisiert werden, um anzuzeigen, dass das Objekt nicht mehr verwendet wird. Die minimale Angabe zum Schließen verweist auf das Objekt. Darüber hinaus bieten einige Dateisysteme die Angabe einer Anordnung des Objekts, die möglicherweise darauf hinweist, dass das Objekt verworfen werden soll und nicht mehr Teil des Dateisystems ist. Ähnlich wie beim Open muss damit gerechnet werden, dass etwas schief gehen kann.

  1. Die Spezifikation des Objekts ist möglicherweise falsch.
  2. Auf dem Medium ist möglicherweise nicht genügend Kapazität vorhanden, um gepufferte Daten zu speichern oder eine Struktur auszugeben, die angibt, dass das Objekt erfolgreich aktualisiert wurde.
  3. Auf dem Medium, auf dem das Objekt gespeichert ist, kann beim Schreiben gepufferter Daten, der Abschlussstruktur oder beim Aktualisieren von Metadaten in Bezug auf das Objekt (z. B. letzte Zugriffszeit) ein Gerätefehler auftreten.
  4. Eine Spezifikation zum Freigeben des Objekts kann mit anderen Prozessen, die das Objekt noch verwenden, inkonsistent sein.

Die Überlegungen zur Behandlung eines Fehlers ähneln denen des Open.

Metadatenverwaltung

Informationen zu den Daten in einer Datei werden als Metadaten bezeichnet.

Einige der Metadaten werden vom Dateisystem verwaltet, z. B. das Datum der letzten Änderung (und verschiedene andere Daten, abhängig vom Dateisystem), der Speicherort des Dateianfangs, die Größe der Datei und das Dienstprogramm zur Sicherung des Dateisystems hat die aktuelle Version der Dateien gespeichert. Diese Elemente können normalerweise nicht von einem Benutzerprogramm geändert werden.

Zusätzliche Metadaten, die von einigen Dateisystemen unterstützt werden, können den Eigentümer der Datei, die Gruppe, zu der die Datei gehört, sowie Berechtigungen und / oder Zugriffssteuerung (dh welchen Zugriff und welche Aktualisierungen verschiedene Benutzer oder Gruppen ausführen dürfen) und ob die Datei enthalten sein ist normalerweise sichtbar, wenn das Verzeichnis aufgelistet ist. Diese Elemente können normalerweise von Dateisystem-Dienstprogrammen geändert werden, die vom Eigentümer ausgeführt werden können.

Einige Anwendungen speichern mehr Metadaten. Bei Bildern können die Metadaten das Kameramodell und die Einstellungen enthalten, die zum Aufnehmen des Fotos verwendet wurden. Bei Audiodateien können die Metadaten das Album, den Künstler, der die Aufnahme aufgenommen hat, und Kommentare zu der Aufnahme enthalten, die für eine bestimmte Kopie der Datei spezifisch sein können (dh verschiedene Kopien derselben Aufnahme können unterschiedliche Kommentare enthalten, wenn sie vom Eigentümer aktualisiert werden der Datei). Dokumente können Elemente wie "eingecheckt", "genehmigt von" usw. enthalten.

Verzeichnisverwaltung

Das Umbenennen einer Datei, das Verschieben einer Datei (oder eines Unterverzeichnisses) von einem Verzeichnis in ein anderes und das Löschen einer Datei sind Beispiele für die vom Dateisystem für die Verwaltung von Verzeichnissen bereitgestellten Vorgänge.

Metadatenvorgänge wie das Zulassen oder Einschränken des Zugriffs auf ein Verzeichnis durch verschiedene Benutzer oder Benutzergruppen sind normalerweise enthalten.

Wartung des Dateisystems

Wenn ein Dateisystem verwendet wird, können Verzeichnisse, Dateien und Datensätze hinzugefügt, gelöscht oder geändert werden. Dies führt normalerweise zu Ineffizienzen in den zugrunde liegenden Datenstrukturen. Dinge wie logisch aufeinanderfolgende Blöcke, die auf eine Weise über das Medium verteilt sind, die eine übermäßige Neupositionierung verursacht, teilweise sogar leere Blöcke verwenden, die in verknüpften Strukturen enthalten sind. Unvollständige Strukturen oder andere Inkonsistenzen können durch Geräte- oder Medienfehler, unzureichende Zeit zwischen der Erkennung eines bevorstehenden Stromausfalls und des tatsächlichen Stromausfalls, einem unsachgemäßen Herunterfahren oder Entfernen des Mediums und in sehr seltenen Fällen Codierungsfehler des Dateisystems verursacht werden.

Spezielle Routinen im Dateisystem sind enthalten, um diese Strukturen zu optimieren oder zu reparieren. Sie werden normalerweise nicht direkt vom Benutzer aufgerufen, sondern im Dateisystem selbst ausgelöst. Interne Zähler der Anzahl der Ebenen von Strukturen, der Anzahl der eingefügten Objekte können mit Schwellenwerten verglichen werden. Diese können dazu führen, dass der Benutzerzugriff auf eine bestimmte Struktur ausgesetzt wird (normalerweise aufgrund des Missfallen des Benutzers oder der betroffenen Benutzer) oder als asynchrone Aufgaben mit niedriger Priorität gestartet werden oder auf eine Zeit mit geringer Benutzeraktivität verschoben werden. Manchmal werden diese Routinen vom Systemmanager aufgerufen oder geplant oder wie im Fall einer Defragmentierung .

API auf Kernel-Ebene

Die API ist "Kernel-Ebene", wenn der Kernel nicht nur die Schnittstellen für die Dateisystementwickler bereitstellt, sondern auch den Bereich, in dem sich der Dateisystemcode befindet.

Es unterscheidet sich vom alten Schema darin, dass der Kernel selbst seine eigenen Funktionen verwendet, um mit dem Dateisystemtreiber zu kommunizieren und umgekehrt, im Gegensatz zum Kernel, der das Dateisystemlayout verwaltet, und dem Dateisystem, das direkt auf die Hardware zugreift.

Es ist nicht das sauberste Schema, sondern behebt die Schwierigkeiten einer größeren Umschreibung, die das alte Schema hat.

Mit modularen Kerneln können Dateisysteme wie jedes Kernelmodul hinzugefügt werden, auch von Drittanbietern. Bei nicht modularen Kerneln muss der Kernel jedoch mit dem neuen Dateisystemcode neu kompiliert werden (und in Closed-Source-Kerneln macht dies das Dateisystem eines Drittanbieters unmöglich).

Unixe und Unix-ähnliche Systeme wie Linux haben dieses modulare Schema verwendet.

Es gibt eine Variation dieses Schemas, das unter MS-DOS (ab DOS 4.0) und kompatiblen Geräten zur Unterstützung von CD-ROM- und Netzwerkdateisystemen verwendet wird. Anstatt wie im alten Schema Code zum Kernel hinzuzufügen oder Kernel-Funktionen wie im kernelbasierten Schema zu verwenden, werden alle Aufrufe einer Datei abgefangen und ermittelt, ob sie zur entsprechenden Funktion des Kernels umgeleitet werden sollen oder müssen wird vom spezifischen Dateisystemtreiber verarbeitet, und der Dateisystemtreiber greift "direkt" mit BIOS- Funktionen auf niedriger Ebene auf den Festplatteninhalt zu .

Treiberbasierte API

Die API ist "treiberbasiert", wenn der Kernel Funktionen bereitstellt, der Dateisystemcode sich jedoch vollständig außerhalb des Kernels befindet (nicht einmal als Modul eines modularen Kernels).

Es handelt sich um ein übersichtlicheres Schema, da der Dateisystemcode völlig unabhängig ist und Dateisysteme für Closed-Source-Kernel und das Hinzufügen oder Entfernen von Online-Dateisystemen aus dem System erstellt werden können.

Beispiele für diese Regelung sind die Windows NT und OS / 2 entsprechenden IFS .

Gemischte Kernel-Treiber-basierte API

In dieser API befinden sich alle Dateisysteme im Kernel, wie in kernelbasierten APIs, aber sie werden automatisch von einer anderen API, die treiberbasiert ist, vom Betriebssystem abgefangen.

Dieses Schema wurde in Windows 3.1 verwendet, um einen FAT-Dateisystemtreiber im 32-Bit-geschützten Modus bereitzustellen und zwischengespeichert (VFAT), der den DOS-FAT-Treiber im Kernel (MSDOS.SYS) vollständig und später in der Windows 9x-Serie ( 95 , 98 und Me ) für VFAT, den ISO9660-Dateisystemtreiber (zusammen mit Joliet), Netzwerkfreigaben und Dateisystemtreibern von Drittanbietern sowie das Hinzufügen der LFN-API zu den ursprünglichen DOS-APIs (die IFS-Treiber können nicht nur die bereits abfangen vorhandene DOS-Datei-APIs, aber auch neue aus der ausführbaren 32-Bit-Modus-Datei hinzufügen).

Diese API wurde jedoch nicht vollständig dokumentiert, und Dritte befanden sich in einem "Make-it-by-yourself" -Szenario, das noch schlimmer war als bei kernelbasierten APIs.

User Space API

Die API befindet sich im Benutzerbereich, wenn das Dateisystem nicht direkt Kernel-Funktionen verwendet, sondern über Betriebssystemfunktionen auf hoher Ebene auf Datenträger zugreift und Funktionen in einer Bibliothek bereitstellt , mit denen eine Reihe von Dienstprogrammen auf das Dateisystem zugreifen.

Dies ist nützlich für den Umgang mit Disk-Images.

Der Vorteil besteht darin, dass ein Dateisystem zwischen Betriebssystemen portierbar gemacht werden kann, da die von ihm verwendeten übergeordneten Betriebssystemfunktionen genauso häufig sein können wie ANSI C. Der Nachteil besteht jedoch darin, dass die API für jede Anwendung, die eine implementiert, eindeutig ist.

Beispiele für dieses Schema sind die hfsutils und die adflib .

Interoperabilität zwischen Dateisystem-APIs

Da alle Dateisysteme (zumindest die Datenträger) gleichwertige Funktionen benötigen, die vom Kernel bereitgestellt werden, ist es möglich, einen Dateisystemcode problemlos von einer API auf eine andere zu portieren, selbst wenn sie unterschiedlichen Typs sind.

Beispielsweise ist der ext2-Treiber für OS / 2 einfach ein Wrapper vom Linux-VFS zum IFS des OS / 2 und zum ext2-Kernel des Linux, und der HFS-Treiber für OS / 2 ist ein Port der hfsutils zum OS / 2's IFS. Es gibt auch ein Projekt, das einen Windows NT IFS-Treiber verwendet, damit NTFS unter Linux funktioniert.

Siehe auch

Verweise

Quellen

  • O'Reilly - Interne Windows NT-Dateisysteme, Ein Entwicklerhandbuch - Von Rajeev Nagar - ISBN  1-56592-249-2
  • Microsoft Press - Innerhalb des Windows NT-Dateisystems - Von Helen Custer - ISBN  1-55615-660-X
  • Wiley - UNIX-Dateisysteme: Evolution, Design und Implementierung - Von Steve D. Pate - ISBN  0-471-16483-6
  • Microsoft Press - In Windows NT - Von Helen Custer - ISBN  1-55615-481-X

Externe Links