Die Tiefen von Windows I/O (Teil 5) — NTFS-Interna: Das Dateisystem anhand des MFT verstehen

Der unsichtbare Zone.Identifier an einer heruntergeladenen Datei. Warum das Kopieren von zehntausend kleinen Dateien so viel langsamer ist, obwohl die Gesamtgröße gleich bleibt. Wie weit die Erklärung „NTFS ist Journaling, also ist es sicher“ wirklich reicht. Das alles lässt sich aus der Ablage der Daten auf dem Datenträger erklären.

Im Zentrum steht die MFT (Master File Table), das Verzeichnis, das Dateien führt. Zuerst fassen wir eine Datei als Sammlung von Attributen auf und gehen dann der Reihe nach durch Daten, Namen, Links, Journale und Datenträgerplatz.

Die Teile 1 bis 3 der Reihe haben den Fluss einer I/O-Anforderung behandelt, Teil 4 die Arbeit des Caches. Diesmal geht es um NTFS, den prominentesten Vertreter des Dateisystems, bei dem die Anforderung am Ende ankommt. Der Blickwinkel wechselt von der dynamischen Geschichte, wie eine Anforderung fließt, zur statischen Struktur, wie Daten liegen.

Dies ist Teil 5 der Reihe „Die Tiefen von Windows I/O“.

Vom konkreten Problem aus lesen

Wer den Mechanismus der Reihe nach lernen will, beginnt bei Abschnitt 2; wer mitten in einer Untersuchung steckt, nutzt die folgende Übersicht. Die Prüfbefehle und die Lesart der Ausgabe sind in Abschnitt 8 gesammelt.

Vorausgesetzte Begriffe dieser Folge

Voraussetzung für diese Folge: Es hilft, die Grundlagen zu IRPs und dem Gerätestapel aus Teil 1 bereits zu kennen. Damit dieser Artikel aber auch für sich allein steht, sind hier die Begriffe aus früheren Teilen definiert, die im Folgenden vorkommen.

Tabelle 1: Begriffe aus früheren Teilen, die in dieser Folge vorausgesetzt werden

Noch etwas: Die beiden Phasen aus Teil 1 — cleanup (wenn das letzte Handle geschlossen wird) und close (wenn jede Referenz im Kernel verschwunden ist) — werden auch in der Erklärung des Datei-Löschens in Abschnitt 4 verwendet.

1. Zuerst das Fazit

Was eine Datei wirklich ist und wo ihre Daten liegen

• NTFS ist rund um die MFT (Master File Table) aufgebaut. Jede Datei wird als Datensatz in diesem Verzeichnis geführt, und alles, was zu einer Datei gehört, liegt entweder „innerhalb des MFT-Eintrags“ oder „in dem Bereich außerhalb der MFT, auf den der Eintrag verweist“ (Abschnitt 2).¹
• Das Wesen einer Datei ist eine Sammlung von Attributen. Eine kleine Datei passt mitsamt ihren Daten vollständig in ihren MFT-Datensatz (resident); eine große Datei besitzt nur einen Verweis auf eine Folge von Clustern (nicht resident). Das erklärt, warum die Verarbeitung riesiger Mengen kleiner Dateien so langsam ist (Abschnitt 2).¹
• Eine Datei kann mehr als einen Datenstrom besitzen (mehrere Datenströme). Die Daten, die man normalerweise sieht, sind der „unbenannte Stream“; mit datei.txt:name kann eine Datei zusätzliche Streams neben sich führen. Das ist die wahre Identität von Zone.Identifier (Mark of the Web) (Abschnitt 3).²

Namen und die Verarbeitung beim Öffnen

• Auch Namen sind Attribute. Wenn ein und derselbe Datensatz mehr als einen Namen trägt, ist das ein Hardlink. Auch der 8.3-Kurzname liegt als „ein weiterer Name“ daneben (Abschnitt 4).³⁴
• Reparsepunkte sind der offizielle Mechanismus für „hier öffnen, dort landen“. Symbolische Links, Junctions und OneDrive-Dateien bei Bedarf sind allesamt Anwendungen dieser mit einem Tag versehenen Daten (Abschnitt 5).⁵⁶

Wiederherstellung nach einem Ausfall und die Zuordnung von Datenträgerplatz

• Es gibt zwei Journale. $LogFile dient der Wiederherstellung der Metadaten-Konsistenz (ein Write-Ahead-Log, damit das Volume nicht beschädigt wird), das USN-Journal dient der Aufzeichnung der Änderungshistorie (ein Verzeichnis dessen, was sich geändert hat). Ihre Rollen sind völlig unterschiedlich (Abschnitt 6).⁷⁸
• „Größe“ und „Größe auf dem Datenträger“ sind zwei verschiedene Dinge. Sparse-Dateien und Komprimierung treiben sie auseinander. Auch der Hintergrund von „eine komprimierte Datei wird nie asynchron“, den wir in Teil 2 gesehen haben, liegt hier begründet (Abschnitt 7).⁹¹⁰

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (35 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Alles ist ein Datensatz in der MFT

2.1. Das Verzeichnis des Volumes

Beim Formatieren eines NTFS-Volumes entstehen die MFT (master file table) sowie eine Reihe von Metadateien, deren Namen mit $ beginnen. Die MFT enthält mindestens einen Eintrag für jede Datei auf dem Volume, und das schließt einen Eintrag für die MFT selbst mit ein.¹

flowchart TB
    subgraph VOL["NTFS-Volume"]
        MFT["$MFT — Master File Table<br/>Das Verzeichnis der Datensätze aller Dateien (einschließlich ihrer selbst)"]
        LOG["$LogFile — Transaktionsprotokoll für<br/>Metadatenoperationen (Abschnitt 6)"]
        BITMAP["$Bitmap — Cluster-Nutzungsstatus"]
        OTH["$Boot / $Secure / $UpCase und<br/>weitere Metadateien"]
        DATA["Benutzerdatenbereich<br/>(Ablageort nicht residenter Daten)"]
    end
    MFT -->|"Datensätze zeigen auf die Lage"| DATA

Abbildung 1: Die Struktur eines NTFS-Volumes. Dass das Dateisystem auch seine eigenen Verwaltungsinformationen als Dateien hält, gehört zum NTFS-Entwurf

Informationen liegen im Datensatz oder in dem externen Bereich, auf den der Datensatz zeigt

Größe, Zeitstempel, Zugriffsrechte und sogar der Inhalt der Daten — jede Information über eine Datei wird entweder innerhalb des MFT-Eintrags oder in einem Bereich außerhalb der MFT, dessen Lage der Eintrag beschreibt, gespeichert.¹

Ein durch Löschen frei gewordener Datensatz wird wiederverwendet, die MFT selbst schrumpft aber nicht

Wird eine Datei gelöscht, wird ihr Eintrag als frei markiert und wiederverwendet. Die Größe der MFT selbst schrumpft jedoch nicht.

Damit die MFT beim Wachstum möglichst zusammenhängenden Platz nutzen kann, ist eine MFT-Zone reserviert. Die offizielle Dokumentation beschreibt auch die Veränderung im Betrieb: Füllt sich das Volume, beginnt die MFT zu fragmentieren.¹

2.2. Eine Datei ist eine Sammlung von Attributen, resident und nicht resident

Der Inhalt eines Dateidatensatzes ist eine Liste von Attributen. Standardinformationen (Zeitstempel und Ähnliches), Dateiname, Sicherheit und Daten werden in diesem Bündel gemeinsam verwaltet.

Wohin die Daten gehen, teilt sich in die folgenden zwei Fälle.

Abbildung 2 zeigt die Verzweigung, Abbildung 3 den Unterschied im Inhalt des Datensatzes.

flowchart TB
    subgraph REC["MFT-Dateidatensatz (Verzeichniseintrag einer Datei)"]
        STD["$STANDARD_INFORMATION-Attribut<br/>Zeitstempel und Attributflags"]
        FN["$FILE_NAME-Attribut<br/>(eine Datei kann mehrere haben — Abschnitt 4)"]
        DATA["$DATA-Attribut"]
    end
    Q{"Sind die Daten klein"}
    RES["Resident<br/>die Daten selbst passen in den Datensatz<br/>ein Lesen endet allein mit einem MFT-Zugriff"]
    NONRES["Nicht resident<br/>der Datensatz hält nur einen Verweis auf eine Clusterfolge<br/>die echten Daten liegen im Benutzerdatenbereich"]
    DATA --> Q
    Q -->|"bis zu einigen hundert Byte"| RES
    Q -->|"größer als das"| NONRES

Abbildung 2: Ein Dateidatensatz ist eine Sammlung von Attributen. Sind die Daten klein, bleiben sie resident im Datensatz

Stellt man denselben Datensatz in der residenten und der nicht residenten Form nebeneinander, wird der Unterschied leichter sichtbar.

flowchart LR
    subgraph RES2["Resident — eine kleine Datei"]
        RA["MFT-Dateidatensatz (feste Länge)<br/>$STANDARD_INFORMATION / $FILE_NAME / Sicherheit<br/>─────────────<br/>$DATA-Attribut = der Inhalt selbst<br/>Einstellung=1 steht direkt hier"]
        RB["Es gibt keinen separaten Ablageort auf dem Datenträger<br/>ein Lesen endet allein mit einem MFT-Zugriff"]
        RA --> RB
    end
    subgraph NON2["Nicht resident — eine große Datei"]
        NA["MFT-Dateidatensatz (feste Länge)<br/>$STANDARD_INFORMATION / $FILE_NAME / Sicherheit<br/>─────────────<br/>$DATA-Attribut = Tabelle der Data Runs<br/>eine Liste: ab wo, wie viele Cluster"]
        NB["Benutzerdatenbereich<br/>Run 1, zusammenhängende Cluster"]
        NC["Benutzerdatenbereich<br/>Run 2, zusammenhängende Cluster an anderer Stelle"]
        NA -->|"zeigt auf die Lage"| NB
        NA -->|"zeigt auf die Lage"| NC
    end

Abbildung 3: Resident gegen nicht resident. Im nicht residenten Fall hält der Datensatz nur die Tabelle, wo die echten Daten liegen und wie viel davon es gibt — die Data Runs

Je mehr Data Runs es gibt, desto mehr verstreute Bereiche müssen beim Lesen einer einzigen Datei durchlaufen werden. Genau das ist die Fragmentierung, die als Nächstes beschrieben wird.

Aus dieser Struktur erklären sich eine ganze Reihe von Phänomenen, denen man im Alltag begegnet.

Beim Kopieren kleiner Dateien stapelt sich die Verzeichnisarbeit pro Datei

Jede einzelne Datei löst Metadatenoperationen aus: Anlegen eines MFT-Datensatzes, Registrieren des Namens, Setzen der Sicherheit. Die Verzeichnisarbeit überwiegt den Datentransfer selbst (und jede dieser Operationen ist außerdem etwas, das die in Teil 6 behandelten Filter prüfen).

Fragmentierung heißt, dass Data Runs über mehrere Bereiche verteilt sind

Nicht residente Daten werden als Liste zusammenhängender Clusterintervalle, der Runs, aufgezeichnet. Lässt sich kein zusammenhängender Platz finden, wächst die Zahl der Runs und damit die Zahl der Suchvorgänge beim Lesen — das ist Fragmentierung. Die tatsächliche Anordnung der Runs lässt sich mit fsutil file layout einsehen.

Auch ein Verzeichnis ist eine Datei, die einen Index zum Nachschlagen von Namen hält

Ein Verzeichnis ist eine Datei, die einen Index von Dateinamen auf MFT-Datensatznummern hält. Auf der Ebene des Verzeichnisses sitzt alles auf demselben Mechanismus.

3. Daten sind nur einer der Streams

3.1. Eine Datei, mehrere Bytefolgen

In NTFS kann eine einzelne Datei mehrere Datenströme halten. Was man normalerweise mit ReadFile/WriteFile liest und schreibt, ist der unbenannte Standardstream, und die Syntax Dateiname:Streamname lässt einen alternativen Datenstrom (ADS) anlegen.²

flowchart LR
    subgraph F["Eine Datei namens report.docx (ein MFT-Datensatz)"]
        D0["Standardstream (unbenannt)<br/>= der Inhalt, den man normalerweise sieht"]
        D1[":Zone.Identifier<br/>Herkunftsinformation (Mark of the Web)"]
        D2[":ein beliebiger Name<br/>zusätzliche Information, die der Anwendung gehört"]
    end

Abbildung 4: Mehrere Datenströme. In der Größenanzeige des Explorers erscheint nur der Standardstream

Zone.Identifier ist der Stream, der Herkunftsinformationen trägt

Ein vertrautes Beispiel ist Zone.Identifier. Woher eine über den Browser heruntergeladene Datei stammt (etwa dass sie aus dem Internet kommt), wird dort aufgezeichnet und wird zum Beleg hinter der SmartScreen-Meldung „Der Computer wurde durch Windows geschützt“ und hinter der geschützten Ansicht von Office.

Wie die Warnung funktioniert, wurde in Warum Windows die Meldung „Der Computer wurde durch Windows geschützt“ anzeigt behandelt. Der Mechanismus auf der anderen Seite, der diese Herkunftsinformation speichert, ist der zusätzliche Stream von NTFS.

3.2. Fallstricke, in die Entwickler treten

Eine gewöhnliche Auflistung oder Größenanzeige zeigt sie nicht

Sie erscheinen weder in der Größenspalte des Explorers noch in einer dir-Auflistung. Prüfen lassen sie sich mit dir /r oder mit Sysinternals streams.¹¹

Je nach Ziel oder Weg gehen sie verloren

Ein ADS ist eine NTFS-Funktion, deshalb verschwindet er leicht beim Kopieren auf einen FAT-formatierten USB-Stick oder über Cloudspeicher. „Die Download-Warnung war nach dem Kopieren weg“ ist genau das.

Aus einer Anwendung heraus nutzbar, aber kein Ort für echte Geschäftsdaten

Es reicht, einen Doppelpunkt in den Pfad zu schreiben, etwa CreateFile("data.txt:meta", ...), um einen solchen Stream zu lesen und zu schreiben.² Das ist bequem, übernimmt aber die Eigenschaft „lässt sich nicht transportieren“ aus dem vorigen Punkt, deshalb gehört hier nicht die Substanz der Geschäftsdaten hin.

4. Auch Namen sind Attribute — Hardlinks und 8.3-Namen

4.1. Hardlinks — mehrere Namen für denselben Datensatz

In Abbildung 2 stand, dass eine Datei mehr als ein Dateinamenattribut halten kann. Innerhalb eines einzelnen Volumes verweisen mehrere Pfade auf eine einzige Datei — das ist ein Hardlink (CreateHardLink / mklink /H).³

flowchart TB
    subgraph DIR1["Der Index von C:\app\"]
        E1["config.json → Datensatz #1234"]
    end
    subgraph DIR2["Der Index von C:\backup\"]
        E2["config-link.json → Datensatz #1234"]
    end
    REC["MFT-Datensatz #1234<br/>die Daten selbst (oder ein Verweis auf ihre Runs)<br/>Linkanzahl 2"]
    E1 --> REC
    E2 --> REC

Abbildung 5: Hardlinks. Die Verzeichnisindizes zeigen einfach auf denselben MFT-Datensatz, und beide Namen sind gleichermaßen echt

Jeder Name zeigt auf dieselbe Datei

Ändert man die Datei über einen beliebigen ihrer Namen, ist es dieselbe Datei, der Inhalt stimmt also sofort überein.³ Statt den einen als Original und den anderen als Kopie zu behandeln, nimmt man es als eine Entität mit mehreren gleichrangigen Namen.

Das Ablösen eines Namens und das Verschwinden der Entität sind verschiedene Dinge

Gibt es Hardlinks, bedeutet DeleteFile „einen Namen ablösen“. Die Entität verschwindet erst, wenn der letzte Name abgelöst ist, jedes geöffnete Handle geschlossen wurde und jede Referenz im Kernel, etwa ein speicherabgebildeter Abschnitt, ebenfalls verschwunden ist.

Die beiden Phasen aus Teil 1, cleanup (wenn das letzte Handle schließt) und close (wenn die letzte Referenz verschwindet), betreffen auch diese Lebensdauer eines Löschvorgangs.

Das Teilen des Inhalts und das Aktualisieren der Attributanzeige sind nicht dasselbe

Ändert man ein Attribut über einen Link, kann die Attributanzeige über einen anderen Link veraltet bleiben. Das ist eine Anzeigeeigenheit, die auch in der offiziellen Dokumentation steht.³

4.2. 8.3-Namen — noch ein versteckter Name

Der Kurzname ist ein Alias zur Kompatibilität

Aus historischer Kompatibilität kann NTFS für einen langen Dateinamen automatisch einen 8.3-Kurznamen wie REPORT~1.DOC erzeugen. Auch das ist ein weiterer Name, der im selben Datensatz lebt.

In einem Ordner mit sehr vielen Dateien kosten das Erzeugen von Kurznamen und das Vermeiden von Kollisionen ebenfalls etwas. Mit fsutil 8dot3name lässt sich die Erzeugung abschalten oder vorhandene Kurznamen entfernen.⁴

Hat eine ältere Anwendung allerdings einen Kurznamen in einem Registrierungspfad festgehalten, zerbricht das Entfernen sie. Genau deshalb gibt es eine Funktion, die die Auswirkungen vor dem Entfernen prüft.⁴

Die Erzeugungseinstellung prüfen, bevor man sich auf Kurznamen verlässt

Ob ein Kurzname überhaupt existiert, hängt von der Umgebung ab. Der Registrierungswert, der das Standardverhalten festlegt, NtfsDisable8dot3NameCreation, kennt die folgenden vier Einstellungen.⁴

Mit 2 lässt sich die Einstellung pro Volume umschalten. „Unter Windows gibt es immer einen Kurznamen wie PROGRA~1“ gilt nicht unbedingt.

Bevor man Code oder ein Verfahren schreibt, das von Kurznamen abhängt, prüft man den Zustand mit fsutil 8dot3name query C:. Lässt man das Volume weg, erhält man die gemeinsame Standardeinstellung aller Volumes.

Die Fallstricke rund um Pfade und Namen (MAX_PATH, reservierte Namen, abschließende Punkte) behandelt MAX_PATH und die Fallstricke von Windows-Pfaden und Dateinamen ausführlich. Die Namensauflösung aus Teil 1 (Object Manager) und dieser Abschnitt (Namen innerhalb des Dateisystems) ergeben zusammen das Gesamtbild der Namen unter Windows.

5. Reparsepunkte — der Mechanismus für „öffnen und woanders landen“

Das Tag entscheidet, was beim Öffnen geschieht

Eine Datei oder ein Verzeichnis kann einen Reparsepunkt tragen. Was er wirklich ist, ist ein Attribut, das ein Tag und benutzerdefinierte Daten hält.

Wird eine Datei mit Reparsepunkt geöffnet, wechselt die Verarbeitung je nach Tag. In manchen Fällen übernimmt ein Filtertreiber, der das Tag versteht; in anderen lässt ein Tag zur Namensumleitung die Auflösung auf dem Zielpfad von vorn beginnen.⁵

sequenceDiagram
    participant App as Anwendung
    participant IOM as I/O-Manager
    participant FS as NTFS

    App->>IOM: CreateFile("C:\data\link.txt")
    IOM->>FS: IRP_MJ_CREATE (die Welt von Teil 1)
    Note over FS: Reparsepunkt am Ziel gefunden<br/>Tag und Daten werden zurückgegeben
    alt Symbolischer Link oder Junction (Namensumleitung)
        FS-->>IOM: der echte Ort liegt hier
        IOM->>FS: Auflösung beginnt auf dem Zielpfad von vorn
    else Vom Filter verwaltetes Tag (Cloud-Dateien und Ähnliches)
        Note over FS: Ein Filter, der das Tag versteht,<br/>übernimmt die Verarbeitung (Teil 6)
    end

Abbildung 6: Auflösung eines Reparsepunkts. Es ist der offizielle Einstieg, der in die Operation „öffnen“ eingreift

Symbolische Links, Junctions und Dateien bei Bedarf

Vertraute Funktionen stehen auf diesem einen Mechanismus.

• Symbolische Links (mklink) — ein Wegweiser, der den Zielpfad hält. Sie können auf ein anderes Volume oder auf einen UNC-Pfad zeigen.⁶
• Junctions und Bereitstellungspunkte — der seit langem bestehende Mechanismus, ein Verzeichnis mit einem Ort auf einem anderen lokalen Volume zu verbinden.³
• OneDrive-Dateien bei Bedarf — eine Datei, deren echte Daten lokal nicht vorliegen, wird als Reparsepunkt dargestellt, und im Moment des Öffnens lädt ein Filter sie herunter und reicht den Inhalt weiter. Das ist die wahre Identität von „im Explorer sichtbar, aber das Öffnen löst Netzwerkverkehr aus“ (der Filtermechanismus selbst kommt in Teil 6).

Code, der einen Baum durchläuft, prüft auf Reparsepunkte

In der Praxis zählt, dass das Ende eines Pfads nicht unbedingt der lokale Ort ist, der er zu sein scheint. Code, der ihre Existenz nicht berücksichtigt, läuft in Probleme wie diese.

• Ein rekursives Durchlaufen läuft an einer Junction in einer Schleife.
• Größensummen werden doppelt gezählt.
• Eine Sicherung löst massenhaft Hydrierung von Cloud-Dateien aus.

Der Einstieg zur Abhilfe ist, FILE_ATTRIBUTE_REPARSE_POINT mit der Familie FindFirstFile zu prüfen.⁵

6. Die beiden Journale — $LogFile und das USN-Journal

„NTFS ist ein Journaling-Dateisystem“ wird oft gesagt, aber NTFS hat zwei Journale mit unterschiedlichen Rollen. Verwechselt man sie, liest man die Garantie falsch.

flowchart TB
    subgraph J1["$LogFile — das Write-Ahead-Log (damit nichts kaputtgeht)"]
        A1["Metadatenoperationen (Aktualisieren von Datensätzen, Umbenennen und Ähnliches)<br/>werden protokolliert, bevor sie ausgeführt werden"]
        A2["Beim nächsten Start nach einem Systemausfall<br/>wird das Protokoll wiedergegeben, um die strukturelle Konsistenz wiederherzustellen"]
        A1 --> A2
    end
    subgraph J2["USN-Journal — die Änderungshistorie (damit man erfährt, was sich geändert hat)"]
        B1["Jede Änderung an einer Datei oder einem Verzeichnis zeichnet<br/>den Inhalt der Änderung und den Namen auf"]
        B2["Sicherung, Suchindex und Synchronisierungswerkzeuge erfahren<br/>ohne vollständigen Scan, was sich seit dem letzten Mal geändert hat"]
        B1 --> B2
    end

Abbildung 7: Die beiden Journale. $LogFile existiert, damit nichts kaputtgeht, das USN-Journal, damit man erfährt, was sich geändert hat

In einer Tabelle sehen die Unterschiede so aus.

Tabelle 2: Die beiden Journale im Vergleich

$LogFile stellt die strukturelle Konsistenz wieder her

$LogFile ist ein Write-Ahead-Log der Metadatenoperationen. Nach einem Systemausfall stellt NTFS beim nächsten Start anhand des Protokolls und der Checkpoint-Informationen die Konsistenz des Dateisystems automatisch wieder her.⁷

Was hier geschützt wird, ist die Konsistenz der Struktur, nicht der in eine Datei geschriebene Dateninhalt. Wie wir in Teil 4 gesehen haben, können dirty Daten im Cache bei einem Stromausfall verloren gehen. „Die Struktur lässt sich wiederherstellen“ und „der Inhalt des letzten Schreibvorgangs bleibt“ sind getrennte Gedanken.

Das USN-Journal ist das Verzeichnis, um zu erfahren, was sich seit dem letzten Mal geändert hat

Jedes Mal, wenn sich eine Datei oder ein Verzeichnis auf dem Volume ändert, zeichnet das USN-Journal den Inhalt der Änderung und den Namen des Ziels auf.⁸

Es ist der Mechanismus, mit dem Sicherungen und Indizierer nur das aufgreifen, was sich seit dem letzten Mal geändert hat, ohne einen vollständigen Scan, und er wird auch genutzt, um nach einem Ausfall den Neuaufbau eines Index zu vermeiden.⁸

In einer Untersuchung kann fsutil usn readjournal als Abgleichsverzeichnis dienen, das Ereignisse ausgleicht, die FileSystemWatcher fallen lässt. Zu den fallen gelassenen Ereignissen selbst siehe Praxisleitfaden für FileSystemWatcher.

7. Sparse-Dateien und Komprimierung — wenn es zwei „Größen“ gibt

In NTFS werden die logische Länge einer Datei und der tatsächlich zugeordnete Platz getrennt verwaltet. Das sind „Größe“ und „Größe auf dem Datenträger“ im Eigenschaftenfenster. Zwei Dinge treiben sie besonders auseinander.

Sparse-Dateien halten Bereiche aus Nullen als „Löcher“

Eine Sparse-Datei ordnet Bereichen, die durchgehend aus Nullen bestehen, keinen realen Speicherplatz zu und verwaltet sie als „Löcher“.⁹ Eine virtuelle Datenträgerdatei mit 42 GB logischer Größe, die auf dem Datenträger nur 500 MB belegt — das kommt ganz gewöhnlich vor. Liest man ein Loch, kommen Nullen zurück; schreibt man hinein, wird genau so viel zugeordnet.

flowchart LR
    subgraph L["Die logische Datei (Größe: 1 GB)"]
        R1["Daten 10 MB"]
        H1["Loch (Nullen) 500 MB"]
        R2["Daten 5 MB"]
        H2["Loch (Nullen) der Rest"]
    end
    subgraph P["Zuordnung auf dem Datenträger (15 MB + Verwaltungsinformationen)"]
        A1["Run: die Substanz von R1"]
        A2["Run: die Substanz von R2"]
    end
    R1 --> A1
    R2 --> A2

Abbildung 8: Eine Sparse-Datei. Ein „Loch“ hat keine Zuordnung, deshalb weichen logische Größe und Größe auf dem Datenträger auseinander

Komprimierung betrifft nicht nur den Verbrauch, sondern auch das Verhalten der I/O

NTFS-Komprimierung komprimiert und speichert Daten je Komprimierungseinheit.¹⁰ Sie ist transparent und bequem, die Kosten sind es aber nicht — bei jedem Lesen und Schreiben laufen Entpacken und erneutes Komprimieren, und Fragmentierung schreitet leichter voran. Und wie wir in Abschnitt 5 von Teil 2 gesehen haben, wird der Zugriff auf eine komprimierte Datei nie asynchron (das Dateisystem wandelt ihn in synchron um). Es ist einer der Orte, die man verdächtigt, wenn „ich auf asynchrone I/O umgestellt habe, aber manche Dateien nicht schneller wurden“.

Vier Faktoren, die man prüft, wenn die Größen nicht übereinstimmen

Die zuordnungsbasierte reale Größe erhält man mit GetCompressedFileSize. Stimmen „Summe der Dateigrößen“ und „belegter Datenträgerplatz“ nicht überein, prüft man der Reihe nach die folgenden vier.

Trennt man die logische Länge vom zugeordneten Platz, lassen sich die Unterschiede in der Anzeige leichter verfolgen.

8. Mit eigenen Augen prüfen

Auch diesmal lässt sich alles auf dem eigenen Windows-Rechner beobachten (ein Teil braucht Administratorrechte). Damit Sie selbst beurteilen können, ob das Ergebnis stimmt, steht bei jedem Befehl, wohin man schaut und was das sagt.

8.1. Ein ADS an der Zeile mit Streamnamen erkennen

:: Alternate Data Streams anzeigen
dir /r C:\Users\%USERNAME%\Downloads

Wohin schauen: Unter den normalen Dateizeilen stehen eingerückte Zeilen der Form Dateiname:Zone.Identifier:$DATA mit ihrer Länge. Ist eine solche Zeile da, trägt diese Datei das Mark of the Web (Abschnitt 3). Über den Browser heruntergeladene Dateien haben es; selbst erzeugte Dateien nicht. Führt man den Befehl an beiden Orten aus und vergleicht, wird das Vorhandensein oder Fehlen eines ADS deutlich.

8.2. Resident und nicht resident sowie die Anordnung der Daten ansehen

:: Anordnung einer Datei auf der MFT (ihre Runs) und ihre Attribute ansehen
fsutil file layout C:\path\to\file.dat

:: Nur die Extents ansehen (ein in der offiziellen Dokumentation beschriebenes Unterkommando)
fsutil file queryextents C:\path\to\file.dat

Wohin schauen: layout listet je Stream Größe und zugeordnete Größe und bei einem nicht residenten Stream eine Liste der Extents (Tripel aus VCN, LCN und Clusteranzahl). Eine sehr kleine Datei, bei der keine Extent-Zeilen erscheinen, ist resident (Abschnitt 2.2), und eine, die über mehrere Zeilen verteilt ist, ist fragmentiert. Den Befehl gegen eine Textdatei von wenigen Byte und gegen eine Datei von einigen hundert Megabyte laufen zu lassen und die beiden zu vergleichen, ist der schnellste Weg, resident gegen nicht resident zu spüren.

8.3. Die Erzeugungseinstellung für Kurznamen mit den tatsächlichen Namen vergleichen

:: Die Erzeugungseinstellung für 8.3-Kurznamen und vorhandene Kurznamen
fsutil 8dot3name query C:
dir /x

Wohin schauen: query gibt zurück, ob die Erzeugung von Kurznamen auf diesem Volume aktiviert oder deaktiviert ist (lässt man das Volume weg, erhält man die gemeinsame Standardeinstellung aller Volumes).⁴ dir /x zeigt neben den langen Namen eine Spalte mit Kurznamen, eine leere Spalte bedeutet also, dass kein Kurzname erzeugt wurde. So lässt sich „es gibt nicht unbedingt einen Kurznamen“ aus Abschnitt 4.2 in der eigenen Umgebung prüfen.

8.4. Zustand des USN-Journals und Fortschritt der Aufzeichnung ansehen

:: Zustand des USN-Journals
fsutil usn queryjournal C:

Wohin schauen: Angezeigt werden die Journal-ID, der Bereich gültiger USNs (First USN / Next USN), die Zielhöchstgröße (MaximumSize) und die Zuordnungseinheit (AllocationDelta).¹² Erzeugt man eine Datei und führt den Befehl erneut aus, sollte Next USN fortgeschritten sein — das bestätigt, dass Änderungen aufgezeichnet werden. MaximumSize ist der grobe Anhalt zu „wie weit man zurückreicht“, den Abschnitt 6 berührt. Auf einem Volume, auf dem das Journal deaktiviert ist, kommt ein Fehler zurück.

8.5. Attribut und Tag eines Reparsepunkts ansehen

:: Reparsepunkte prüfen (Ziel und Tag)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

Wohin schauen: Was dir /aL auflistet, ist ein Reparsepunkt (etwas mit gesetztem FILE_ATTRIBUTE_REPARSE_POINT). Symbolische Links und Junctions werden mit einem Typ wie <SYMLINKD> oder <JUNCTION> angezeigt. fsutil reparsepoint query zeigt den Wert des Reparse-Tags und, bei einem Tag zur Namensumleitung, den Zielpfad. Zeigt man auf etwas, das kein Reparsepunkt ist, kommt ein Fehler zurück, ein Fehler ist also selbst die Bestätigung, dass dies ein gewöhnlicher Ordner ist.

8.6. Echte Dateioperationen mit Procmon verfolgen

Verfolgt man Dateioperationen mit Procmon, laufen die Figuren dieses Artikels unter ihrem echten Namen vorbei (Schreiben nach $LogFile, Pfade mit Streamnamen, Reparse-Verarbeitung). Zur Verwendung siehe Process Monitor (ProcMon) Praxisleitfaden.

9. Zusammenfassung

• NTFS ist rund um die MFT aufgebaut. Jede Datei ist ein Datensatz im Verzeichnis, und ihre Information sitzt entweder im Datensatz oder in dem externen Bereich, auf den der Datensatz zeigt. Kleine Daten sind resident, große Daten werden über Runs referenziert, und die Langsamkeit bei der Verarbeitung riesiger Mengen kleiner Dateien sowie die Fragmentierung sind Folgen dieser Struktur.¹
• Eine Datei kann mehr als einen Datenstrom halten. Zone.Identifier (Mark of the Web) ist nichts als ein ADS: Er ist mit dir /r sichtbar und wird nicht über NTFS hinaus mitgenommen.²¹¹
• Namen sind Attribute, und eine Datei kann mehrere davon halten. Ein Hardlink ist ein gleichrangiger Name, der auf denselben Datensatz zeigt; der 8.3-Name ist ein weiterer Name zur Kompatibilität. Löschen bedeutet, einen Namen abzulösen, und die Entität verschwindet erst, wenn der letzte Name, das letzte Handle und jede Referenz im Kernel (ein abgebildeter Abschnitt und Ähnliches) alle weg sind.³⁴
• Ein Reparsepunkt ist der offizielle Einstieg in „öffnen“, und symbolische Links, Junctions und Dateien bei Bedarf sind allesamt Anwendungen davon. Code, der einen Baum durchläuft, muss FILE_ATTRIBUTE_REPARSE_POINT im Blick behalten.⁵⁶
• Es gibt zwei Journale. $LogFile stellt die strukturelle Konsistenz wieder her (damit nichts kaputtgeht); das USN-Journal ist die Änderungshistorie (was sich geändert hat). „Es ist Journaling, also sind auch die Daten sicher“ folgt daraus nicht — die Haltbarkeit der Daten wird mit den Werkzeugen aus Teil 4 hergestellt.⁷⁸
• Logische Größe und Zuordnung sind verschiedene Dinge. Sparse-Dateien, Komprimierung, ADS und Cluster-Aufrundung sind die vier großen Ursachen dafür, dass „die Größen nicht übereinstimmen“. Zusammen mit der Tatsache, dass eine komprimierte Datei nie asynchron wird, gehört das ins Repertoire einer Leistungsuntersuchung.⁹¹⁰

Die Reihe schließt das nächste Mal in Teil 6, Filtertreiber und Minifilter — Warum Procmon und Virenscanner sich in die I/O einklinken können. Wie klinken sich die, die seit Teil 1 gelegentlich aufgetreten sind — Virenschutz, Procmon, OneDrive, Verschlüsselung — tatsächlich in die I/O ein? Als Abschluss der Reihe zeigen wir die Identität der Bewohner, die in den Lücken des Gerätestapels stehen.

Verwandte Artikel

• Die Tiefen von Windows I/O (Teil 1) — Jedes Lesen und Schreiben wird zu einem IRP: Das Gesamtbild des I/O-Systems
• Die Tiefen von Windows I/O (Teil 2) — Synchrones und asynchrones I/O: Was OVERLAPPED wirklich bedeutet
• Die Tiefen von Windows I/O (Teil 4) — Cache-Manager: Wann erreicht Ihr WriteFile tatsächlich die Festplatte?
• Warum Windows die Meldung „Der Computer wurde durch Windows geschützt“ anzeigt
• MAX_PATH und die Fallstricke von Windows-Pfaden und Dateinamen ── Das 260-Zeichen-Limit, reservierte Namen, abschließende Punkte und Groß-/Kleinschreibung
• Praxisleitfaden für FileSystemWatcher - Umgang mit verpassten und doppelten Ereignissen
• Die Fallstricke von Netzlaufwerken und UNC-Pfaden ── Fileserver (Freigabeordner) in Business-Anwendungen richtig einsetzen
• Process Monitor (ProcMon) Praxisleitfaden — „Konfiguration wird nicht gelesen“ und ACCESS DENIED in 10 Minuten identifizieren

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt Entwurf und Untersuchung von Windows-Geschäftsanwendungen, die in der Arbeitsweise von NTFS wurzeln, einschließlich rätselhaften Verhaltens bei Dateigröße und Kopierleistung sowie Fehlern rund um Links und Streams.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Nutzung und Migration bestehender Assets
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist die MFT (Master File Table)?

Es handelt sich um die Datenstruktur im Herzen eines NTFS-Volumes: ein Verzeichnis, das für jede Datei auf dem Volume mindestens einen Eintrag (einen Dateidatensatz) enthält — einschließlich eines Eintrags für die MFT selbst. Alles, was zu einer Datei gehört, von Größe, Zeitstempeln und Zugriffsrechten bis hin zum eigentlichen Dateninhalt, wird entweder innerhalb eines MFT-Eintrags gespeichert oder in einem Bereich außerhalb der MFT, auf den der Eintrag verweist. Eine kleine Datei passt vollständig, mitsamt ihren Daten, in ihren MFT-Eintrag (resident); eine große Datei besitzt im Eintrag nur einen Verweis auf die Lage ihrer Daten (eine Folge von Clustern) (nicht resident). Wird eine Datei gelöscht, wird ihr Eintrag als frei zur Wiederverwendung markiert, aber die Größe der MFT selbst schrumpft dadurch nie.

Was ist die unsichtbare „Zone.Identifier“-Information, die an Dateien hängt?

Sie ist einer der mehreren Datenströme (alternativen Datenströme) von NTFS. In NTFS kann eine einzelne Datei mehrere Bytefolgen (Streams) enthalten; normalerweise liest und schreibt man den unbenannten Standardstream. Windows speichert die Herkunft einer Datei — etwa dass sie aus dem Internet heruntergeladen wurde — in einem zusätzlichen Stream, den man mit einem Doppelpunkt angibt, wie in „file.txt:Zone.Identifier“. Das ist das sogenannte „Mark of the Web“, und genau darauf stützen sich SmartScreen und die geschützte Ansicht von Office bei ihrer Beurteilung. Alternative Streams erscheinen nicht in der Größenanzeige des Explorers; man kann sie mit dem Befehl dir /r oder dem Sysinternals-Tool streams prüfen. Zu beachten ist außerdem, dass sie beim Kopieren auf ein Nicht-NTFS-Dateisystem wie FAT nicht erhalten bleiben.

Was ist der Unterschied zwischen einem Hardlink und einem symbolischen Link?

Ein Hardlink ist „ein weiterer, gleichrangiger Name, der auf dasselbe Dateiobjekt — denselben MFT-Datensatz — verweist“. Er lässt sich nur innerhalb desselben Volumes erstellen, der Zugriff über jeden seiner Namen liefert dieselbe Datei, und das Löschen eines Namens entfernt die Datei nicht, solange ein anderer Name noch existiert. Ein symbolischer Link ist „ein Wegweiser, der auf einen anderen Pfad verweist“, implementiert als Reparsepunkt. Da er nur den Zielpfad als Zeichenkette hält, kann er auf ein anderes Volume oder sogar einen entfernten Ort verweisen, wird aber zur Sackgasse, wenn das Ziel verschwindet. In der Praxis gilt als Faustregel: Ein Hardlink dient dazu, dasselbe Dateiobjekt zu teilen (was die Bedeutung von „Löschen“ verändert), ein symbolischer Link dazu, einen Pfad umzuleiten (für Umzüge oder Weiterleitungen).

NTFS ist ein Journaling-Dateisystem — bedeutet das, dass bei einem Stromausfall keine Daten verloren gehen?

Man muss genau verstehen, was hier tatsächlich geschützt wird. Was das Transaktionsprotokoll von NTFS ($LogFile) schützt, ist die Konsistenz der Struktur des Dateisystems (seiner Metadaten). Kommt es zu einem Systemausfall, stellt NTFS beim nächsten Start die Konsistenz mithilfe des Protokolls automatisch wieder her und verhindert so, dass das Volume beschädigt und unlesbar wird. Das bedeutet aber nicht, dass der tatsächliche Inhalt einer Datei, die gerade mitten im Schreiben war, wiederhergestellt wird. Wie wir in Teil 4 dieser Serie gesehen haben, gehen im Cache liegende, noch nicht geschriebene (dirty) Daten bei einem Stromausfall verloren. Das richtige Verständnis lautet also: „Das Volume geht nicht kaputt, aber der Inhalt des letzten Schreibvorgangs kann trotzdem verloren gehen“ — wer Haltbarkeit für die Daten selbst benötigt, muss sie selbst einbauen, etwa mit FlushFileBuffers, WRITE_THROUGH oder einem anwendungsseitigen Schreibdesign wie „erst in eine temporäre Datei schreiben, dann umbenennen“.

Warum unterscheiden sich „Größe“ und „Größe auf dem Datenträger“ bei einer Datei?

Weil NTFS die logische Länge einer Datei und den tatsächlich dafür reservierten Speicherplatz getrennt verwaltet. Selbst bei einer gewöhnlichen Datei entsteht ein gewisser Unterschied, weil die Zuordnung auf ganze Cluster (standardmäßig 4 KB) aufgerundet wird, aber richtig groß wird die Lücke bei Sparse-Dateien und komprimierten Dateien. Eine Sparse-Datei weist Bereichen, die durchgehend aus Nullen bestehen, keinen realen Speicherplatz zu — sie verwaltet sie als „Löcher“ —, sodass eine Datei mit mehreren Gigabyte logischer Größe durchaus nur wenige Megabyte auf dem Datenträger belegen kann. Bei einer komprimierten Datei wird nur die Größe nach der Komprimierung zugewiesen. Erscheint umgekehrt die „Größe auf dem Datenträger“ größer, liegt die Ursache oft in der Rundung auf Cluster oder in einem alternativen Datenstrom.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.