What Is the NTFS Journal and Why It Keeps Growing

Two logs, two jobs

The first log is $LogFile, NTFS's own write-ahead journal for metadata. Before NTFS changes anything structural — a file's size, its location on disk, a directory entry — it writes the intended change to $LogFile first, so that a power cut mid-operation leaves the volume mountable and mostly intact. It is capped by design and wraps in place, a few MB to a few tens of MB; you never manage it, and no cleanup tool should touch it.

The second is the one people actually meet: $UsnJrnl:$J, the USN (Update Sequence Number) change journal, a chronological record of changes on the volume — files created, renamed, deleted, written. It exists so that applications don't have to rescan a whole disk to learn what changed since their last look.

• the Windows Search indexer — knows exactly what to reindex
• backup software — detects changed files without walking the whole tree
• cloud sync clients — upload only what actually moved
• instant-search tools like Everything — keep their index current
• enterprise DLP and eDiscovery agents — audit file events
• some antivirus products — track file activity between full scans

Why it grows, and when that matters

The USN journal grows with change traffic: compile jobs, browser caches, photo libraries being reorganized — every create, rename, and delete appends a small record. Its maximum size is configurable, and applications can raise it; a sync or backup agent may ask for a large journal precisely so that it never misses a change while it was offline. When the journal hits its cap, it wraps: the oldest records are overwritten. In other words, a big journal is usually a deliberate setting, not a leak — and it shows up as "unexplained" used space because it lives in NTFS metadata, where file managers can't see it.

What it does not do is slow anything down. Appends are tiny sequential writes, and the readers — search, backup, sync — would burn far more CPU rescanning the disk without it. The cost of the journal is space, not speed.

What to do (and what not to do)

Usually: nothing. If you want to see yours, run fsutil usn queryjournal C: as admin — it reports the journal ID and record statistics. If you genuinely need the space and can afford a rescan storm, fsutil usn deletejournal /D C: is safe: it deletes the change records, not your files, and the journal is recreated. Expect Search and sync tools to do a full rescan right after — a one-time spike of CPU and disk activity that rather defeats the point.

What you should never do is go hunting for $LogFile: it is metadata, not a file, and nothing user-facing can delete it without breaking the volume. If your journal has grown enormous, the productive question is not "how do I shrink it" but "which application raised the cap" — that answer tells you whether it's your backup tool, your sync client, or something you'd forgotten was running.

Questions and Answers

Read next