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 journal-less filesystem. "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.