Failure scenario: root filesystem is ext3 with external journal. The external
journal device is lost due to hardware failure. The system can no longer boot
to run fsck. It should be possible to mount the filesystem in a read-only state
to run fsck and recreate the journal internal to the filesystem.
It's a design feature --- you *must* run fsck before you can mount a
"Hot" filesystem blocks can be left permanently in the journal on a busy box ---
there may never be a point at which the journal copy goes cold so we can update
the on-disk copy. We need a fsck to have any assurance that what we're mounting
looks even remotely sane.
It still needs fixed, but I think that the _right_ fix is to have an e2fsck
option to wipe the journal and fsck the filesystem as ext2, rather than to have
the kernel deal with this.
Incidentally, clearing the journal can already be done in this case via tune2fs
--- it's purely an admin UI enhancement to make it happen automatically or to
allow e2fsck to do it via command-line switches.
My concern is exactly what happens for the root case: fsck and other programs
are still on the filesystem and undamaged (they're not written to in normal
operation), so it should be possible to limp along in read-only mode. Disabling
remount to rw would make sense if such a damaged filesystem had to be mounted,
but not being able to mount it at all is more of a problem.
Yes, but that's nothing to do with the external journal --- any journal
corruption can affect the root case.
I'm still not sure what to do about that, but I think I can do a
"forever-readonly" mode which prohibits ever going read-write and which disables
all recovery for emergency use. However, I'd want that to be a mount-time
option, and that means that initrd would need extra smarts to pass the option to
mount for the root fs.
One of the many reasons why external journals on the root dev are not supported.