Robert Hancock wrote: > Martin MOKREJŠ wrote: >> Duane Griffin wrote: >>> 2009/1/3 Martin MOKREJŠ <mmokrejs@xxxxxxxxxxxxxxxxxxxxxx>: >>>> Hmm, so if my dual-boot machine does not shutdown correctly and I boot >>>> accidentally in M$ Win where I use ext2 IFS driver and modify some >>>> stuff on the ext3 drive, after a while reboot to linux and the journal >>>> get re-played ... Mmm ... >>> You *really* wouldn't want to be doing that. >>> >>> The other scenario that people have reported trouble with is >>> suspending the system, booting a live CD which "read-only" mounts the >>> filesystem (and replays the journal), then resuming. >> >> Why does not "mount -ro" die when it would have to replay the journal >> with a message that user must run fsck.ext3 in order to be able to mount >> it albeit read-only? Still I would prefer having an extra switch to > > That would break typical system bootup in the unclean journal case, > normally the root FS is mounted read-only to start with (which replays > the journal) and remounted read-write later on - and usually the fsck > utilities are located on the root filesystem.. Couldn't that be handled by e.g. openRC during boot, to provide the say to be provided --force-journal-replay during "normal" boot? Yes, that would mean e2fsprogs would become incompatible with older versions but why not "fix" the logic? > >> force mount RO while not touching the journal for disk forensics. I >> think that would also prevent the cases when a LiveCD/rescue >> distribution would not mount+replay it automagically but user would >> really have to provide the switch to the command. I am really not >> using the recovery boot cd to touch my partitions in some cases >> unwillingly. > > I agree, there should be a way to force it to mount "really read only" > so it doesn't try to replay the journal. That might require just > ignoring the journal content, which may result in the FS appearing > corrupt, but for recovery/forensics purposes that seems better than > nothing.. Fully agree. M. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html