Filesystem Journaling
Also known as: journaling explained, fs journal, filesystem journaling
Filesystem journaling records pending changes in a dedicated log before applying them to the main filesystem. After a crash or power loss, the journal is replayed or discarded so the filesystem stays consistent instead of corrupted.
- Journaling logs an intended change as a transaction before applying it, so a crash leaves the filesystem consistent.
- ext4, APFS, NTFS, and F2FS all provide journaling or equivalent crash-consistency mechanisms.
- A journal protects filesystem structure, not your data's value, a committed delete is still permanent and it is not a backup.
How journaling works
An operation like creating, deleting, or growing a file touches several on-disk structures (directory entries, inode tables, free-space maps). If power is lost partway through, those structures can disagree and corrupt the filesystem. A journal is a reserved area where the filesystem first writes a description of the intended change as a transaction, then applies it to the real locations, then marks the transaction complete.
On recovery the filesystem inspects the journal. Completed transactions are already safe; incomplete ones are either replayed to finish them or rolled back, so the filesystem returns to a consistent state without a slow full scan. Many filesystems offer modes that journal only metadata for speed, or both metadata and data for stronger guarantees.
Where it is used
Journaling is standard on the filesystems behind today's phones and computers. ext4 uses the jbd2 journal, APFS on iOS and macOS uses a copy-on-write design plus metadata journaling, NTFS on Windows journals metadata, and F2FS on many Android devices is designed around flash with its own consistency mechanisms.
Journaling protects integrity but is not a backup, it guards filesystem structure, not the value of your data, and a committed deletion is still gone. It also adds some write overhead, which flash-oriented filesystems try to minimize.
Why it matters for deletes and cleanup
Because deletions and large writes are journaled, a cleanup that is interrupted by a crash leaves the filesystem consistent rather than half-broken, the operation is either finished or undone, never partial on disk. This is what makes bulk removals safe even on a phone that loses power mid-clean.
It also means freed space may not appear instantly until the relevant transaction commits and caches flush. A well-behaved tool like Cleanor relies on the OS file APIs so deletions ride the same journaled, crash-safe path the system uses everywhere else.