ext4 & XFS Internals for Responders

In File System Forensics you read timestamps and hunted hidden names with stat, ls, and find. Those tools hand you a tidy, filtered view of the disk. This lesson goes one layer down — to the structures the kernel actually writes to the platter — because three core jobs of incident response are impossible to do well without that layer:

• Recovery. When a file is 'deleted,' how much of it is really gone? The answer depends entirely on what the filesystem stores and where. You can't make a recovery call without knowing the on-disk model.
• Timeline accuracy. A timeline is only as trustworthy as the timestamps feeding it. Where those timestamps physically live — and which ones the standard tools quietly hide from you — decides whether your timeline is complete or has a blind spot.
• Tamper detection. Spotting a forged file means understanding what must be consistent on disk and what an attacker can or can't rewrite. You can't spot an inconsistency you don't know should exist.

The filesystem isn't a black box that 'stores files.' It's a records system, and a responder who understands the records reads them the way an auditor reads a ledger.

Here is the single most important idea in this lesson: a file is not its name. On Linux, the real file — owner, permissions, size, timestamps, and the pointers to its data blocks — lives in a fixed-size record called an inode. The name you see in a directory is a separate, tiny structure called a directory entry (dentry), and all it contains is a name and the inode number it points to.

Think of the inode as a shipping manifest in a warehouse: it lists exactly what's in the crate, who owns it, when it arrived, and which shelf locations (data blocks) hold the contents. The directory entry is just a luggage tag tied to the crate's handle, printed with a human-friendly label and the manifest's ID number. Tear the luggage tag off and throw it away, and the crate, its contents, and its manifest are all still sitting on the shelf — you've only removed the label that pointed to them.

This is exactly what 'deleting' a file usually does. rm removes the directory entry (the tag) and decrements the inode's link count. If nothing else links to that inode, the filesystem marks the inode and its data blocks as free — but it does not scrub them. Until something reuses that space, the manifest and the crate's contents are recoverable. That's the whole basis of deleted-file recovery.

If inodes are the manifests, the superblock is the front-desk master ledger for the whole warehouse: how big the filesystem is, the block size, how many inodes exist and how many are free, the volume UUID, the mount count, and which optional features are enabled. There's a primary superblock near the start of the device and backup copies scattered across the disk — because if the master ledger is corrupted, recovery depends on those backups.

ext4 doesn't store all its inodes in one pile. It divides the disk into block groups, each a self-contained chunk with its own slice of inodes, its own data blocks, and bitmaps tracking what's used. Spreading metadata across groups keeps related data physically close (less seeking) and means damage to one region doesn't doom the entire filesystem. For a responder, the practical payoff is knowing where to look: the superblock tells you the inode count and block size you need to interpret everything else, and the group layout explains how inodes map to physical locations.

First, always confirm which filesystem you're standing on — the tooling forks completely from here.

stat shows you three timestamps — atime, mtime, ctime — and stops. But a 256-byte ext4 inode actually stores a fourth: crtime, the creation (birth) time, also called btime. This is the genuine answer to 'when did this file first come into existence' — and the classic stat() API never exposed it, which is why generations of responders learned to (wrongly) treat ctime as 'created.' It isn't: ctime is inode-change time. The real birth time was there on disk all along; the tools just didn't surface it.

debugfs is the ext4 internals console. It lets you open the raw filesystem and inspect inodes directly — by number or by path — bypassing the friendly abstractions. It's the responder's window into the manifest exactly as it sits on the platter.

A filesystem write is rarely a single atomic act — updating one file can mean touching the inode, the data blocks, and several bitmaps. If power dies halfway through, you'd be left with a half-finished change and an inconsistent disk. ext4's journal prevents that. It's a reserved area (you saw Journal inode: 8 in the superblock) where the filesystem first records what it's about to do. After a crash, it replays the journal to finish or roll back incomplete operations, so the disk comes back consistent without a full scan.

The analogy: the journal is a construction site's work-order log. Before any crew touches the building, the change is written into the log. If a storm hits mid-job, the foreman reads the log and either completes the half-done work order or tears it back out — the building never ends up in a broken in-between state.

Ext4 offers three journaling modes that trade safety for speed:

• journal — both metadata and file data go through the journal. Safest, slowest.
• ordered (the default) — only metadata is journaled, but data blocks are forced to disk before their metadata commits. A strong safety/speed balance.
• writeback — only metadata is journaled, with no ordering guarantee for data. Fastest, but after a crash a file's metadata can point at stale or garbage blocks.

Walk onto a RHEL/Rocky 8 box and findmnt will likely say xfs, not ext4. XFS stores the same concepts — inodes, directories, a superblock, journaling, timestamps including a real birth time — but the structures and, critically, the tooling are different. None of your dumpe2fs/debugfs/tune2fs muscle memory works here; reach for those on XFS and you'll just get errors.

The big structural differences a responder should internalize:

• Allocation is B+tree-based. Where ext4 uses block-group bitmaps and extents, XFS organizes free space and inodes with B+trees within allocation groups (its rough analog of block groups). The effect is excellent scaling to huge filesystems and many parallel operations — but it means recovery and analysis tools must understand the trees, not bitmaps.
• Inodes are allocated dynamically, not pre-created at format time, so 'inodes per group' isn't a fixed up-front number the way ext4's superblock reports it.
• The journal is internal and replay-on-mount, like ext4's, with the same evidence caution — but it has no ext-style external-journal-device replay tuning and no data= ordered/writeback knob; XFS journals metadata only, by design.
• XFS is grow-only. You can xfs_growfs a mounted filesystem larger, but XFS cannot be shrunk — there's no supported shrink. That's an operational fact worth knowing, and a hint that XFS is built for large, growing storage.

The tooling maps across cleanly once you know the pairs: dumpe2fs → `xfs_info`/`xfs_db`, debugfs → `xfs_db`, fsck.ext4 → `xfs_repair`.

You have a real root shell. Run this sequence in order — it's the exact 'identify the filesystem, then read its internals' opening you'd use on a disk-forensics call. Every command here is read-only; nothing modifies the filesystem. The point is to make the moves reflex: first find out what you're on, then read the inode and its hidden timestamps, then drop into the right internals tool for your filesystem.