Question 1647

Committed Or Not

An ext3-style file system runs in ordered (metadata) journaling mode. An application appends one 4 KB block to an existing file. Three things change: the inode I[v2] (new size, new pointer to data block 5), the data bitmap B[v2] (block 5 now allocated), and the data block Db itself.

The file system issues:

step write status
1 Db to its final home, block 5 completed
2 TxB, I[v2], B[v2] to the journal completed
3 TxE to the journal power lost here, never issued
4 checkpoint I[v2], B[v2] not reached

The machine reboots and journal recovery runs. What does the file system look like?

A

Block 5 is leaked. The bitmap marks it allocated but no inode refers to it, so the space is unreachable until a full scan reclaims it.

B

The append is silently gone. With no TxE the transaction never committed, so recovery skips it: the inode still has the old size and no pointer to block 5, and the bitmap still says block 5 is free. Block 5 physically holds the new bytes, but nothing references them.

C

Recovery replays the transaction, because I[v2] and B[v2] are both intact in the journal and the file system prefers the newer versions it finds there.

D

The metadata is left inconsistent: the inode points at block 5 while the bitmap calls it free, so the volume must be taken offline and repaired with fsck.