[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <495FFBA8.10804@shaw.ca>
Date: Sat, 03 Jan 2009 17:58:32 -0600
From: Robert Hancock <hancockr@...w.ca>
To: linux-kernel@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: document ext3 requirements
Martin MOKREJŠ wrote:
> Duane Griffin wrote:
>> 2009/1/3 Martin MOKREJŠ <mmokrejs@...osome.natur.cuni.cz>:
>>> 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..
> 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..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists