Was ist das NTFS-Journal – und warum wächst es ständig?

Zwei Protokolle, zwei Aufgaben

Das erste ist $LogFile, NTFS' eigenes Write-Ahead-Protokoll für Metadaten. Bevor NTFS irgendetwas Strukturelles ändert — die Größe einer Datei, ihre Lage auf der Platte, einen Verzeichniseintrag — schreibt es die beabsichtigte Änderung zuerst nach $LogFile, damit ein Stromausfall mitten in der Operation den Datenträger mountbar und meist intakt lässt. Es ist von Design her begrenzt und überschreibt sich zirkulär, ein paar MB bis ein paar zig MB; Sie verwalten es nie, und kein Cleanup-Tool sollte es anfassen.

Das zweite ist das, was Menschen tatsächlich begegnen: $UsnJrnl:$J, das USN-Änderungsjournal (Update Sequence Number), eine chronologische Aufzeichnung der Veränderungen auf dem Datenträger — Dateien erstellt, umbenannt, gelöscht, geschrieben. Es existiert, damit Anwendungen nicht die ganze Platte neu einlesen müssen, um zu erfahren, was sich seit ihrem letzten Blick geändert hat.

der Windows-Such-Indexer — weiß genau, was neu zu indizieren ist
Backup-Software — erkennt geänderte Dateien ohne Durchlauf des ganzen Baums
Cloud-Sync-Clients — laden nur hoch, was sich wirklich bewegt hat
Sofort-Suchwerkzeuge wie Everything — halten ihren Index aktuell
DLP- und eDiscovery-Agenten — protokollieren Dateiereignisse
manche Virenscanner — verfolgen Dateiaktivität zwischen Vollscans

Warum es wächst – und wann das zählt

Das USN-Journal wächst mit dem Änderungsaufkommen: Builds, Browser-Caches, neu sortierte Fotoarchive — jedes Erstellen, Umbenennen und Löschen hängt einen kleinen Datensatz an. Die Maximalgröße ist konfigurierbar, und Anwendungen dürfen sie anheben; ein Sync- oder Backup-Agent fordert ein großes Journal gerade deshalb, um während seiner Abwesenheit keine Änderung zu verpassen. Erreicht das Journal seine Obergrenze, überschreibt es sich: Die ältesten Datensätze weichen. Ein großes Journal ist also meist eine bewusste Einstellung, kein Leck — und es erscheint als „unerklärter“ belegter Platz, weil es in den NTFS-Metadaten lebt, wo Dateimanager nicht hinschauen.

Was es nicht tut, ist verlangsamen. Die Anhänge sind winzige sequenzielle Schreibvorgänge, und die Leser — Suche, Backup, Sync — würden ohne das Journal weit mehr CPU in Neu-Scans verbrennen. Die Kosten des Journals sind Platz, nicht Tempo.

Was tun (und was lassen)

Üblicherweise: nichts. Wer das eigene sehen will, führt als Admin fsutil usn queryjournal C: aus — es meldet die Journal-ID und Datensatz-Statistik. Wenn Sie den Platz wirklich brauchen und eine Neu-Scan-Welle verkraften können, ist fsutil usn deletejournal /D C: sicher: Es löscht die Änderungsdatensätze, nicht Ihre Dateien, und das Journal wird neu angelegt. Rechnen Sie danach mit einem Voll-Rescan von Suche und Sync — ein einmaliger Spitzenwert an CPU und Datenträger, der den Sinn der Aktion gleich wieder aufisst.

Was Sie nie tun sollten, ist Jagd auf $LogFile machen: Es ist Metadatum, keine Datei, und nichts Benutzerseitiges kann es löschen, ohne den Datenträger zu beschädigen. Ist Ihr Journal enorm gewachsen, lautet die produktive Frage nicht „wie verkleinere ich es“, sondern „wer hat die Obergrenze angehoben“ — die Antwort verrät, ob es Ihr Backup, Ihr Sync-Client oder etwas ist, von dem Sie vergessen hatten, dass es läuft.

Fragen und Antworten

Kann man das USN-Journal löschen?

Ja. fsutil usn deletejournal /D C: entfernt nur die Änderungsdatensätze, nicht Ihre Dateien. Das Journal wird neu angelegt, Suche und Sync scannen neu — erwarten Sie einen einmaligen Anstieg von CPU- und Datenträgerlast.

Verlangsamt das NTFS-Journal den Computer?

Nein. Das Schreiben in das Journal ist ein Strom winziger sequenzieller Anhänge. Sie zahlen mit Speicherplatz, nicht mit Tempo — ohne das Journal würden Suche, Backup und Sync weit mehr CPU für Neu-Scans verbrennen.