Hello Samuel,
Yeah, under normal operation, the journal completely eliminates the need
for fsck.
However, a hard reset during a deadlocked state is the one edge case where
we are forced to intentionally break the Write-Ahead Log (WAL) guarantee to
give the system a fighting chance.
We handle the Mach pager this way: when the system is under extreme memory
pressure, the Mach pager rushes the ext2fs pager to flush blocks to disk.
Because there is no mechanism to tell the Mach pager to "come back later"
or "wait for the commit to finish" (blocking it causes an instant hard
deadlock), we intercept those rushed writes into our finite ext2_lifeboat
cache to preserve the WAL ordering.
This works perfectly under normal heavy load. But if the system hits a true
lockup (like a driver lockup), the active transaction can't commit, and the
ext2_lifeboat eventually fills up.
Once the lifeboat is exhausted, we hit a hard architectural choice:
intentionally crash the translator, or allow the pager to bypass the WAL
and write the blocks directly to disk to keep the memory manager moving. We
chose survival, which triggers this warning:
/* Failure: Lifeboat full. Trigger V4 WAL bypass */
JRNL_LOG_WARN("VM Deadlock & Lifeboat Full! Bypassing WAL for block %u.",
b);
Normally, if the lockup clears, the next journal commit fixes the on-disk
state. But if you are forced to hard-reset the machine while it is in this
WAL-bypassed state, the disk and journal have a discrepancy, and fsck
correctly flags it on the next boot.
In short: the journal saves us from fsck during normal sudden power losses.
But if a driver deadlocks and forces the lifeboat to overflow before the
hard reset, fsck becomes our necessary safety net. We could technically
increase the lifeboat size, but since this only happens during actual
deadlocks, the current size seems like the most practical trade-off.
Kind regards,
Milos
On Mon, Jun 29, 2026 at 12:34 PM Samuel Thibault <[email protected]>
wrote:
> Milos Nikic, le jeu. 25 juin 2026 21:18:54 -0700, a ecrit:
> > As far as:
> > /dev/sd3: Superblock needs_recovery flag is clear, but journal has data.
> > /dev/sd3: Run journal anyway
> >
> > That happens if it locks up and it has to be restarted, because journal
> didn't
> > manage to commit/checkpoint so things are still there.
> > The issue is that it locked up on real machine.
>
> Mmmm, but isn't journalling supposed to save us from having to run
> fsck?
>
> Samuel
>
