[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <495FF9CE.2020908@ribosome.natur.cuni.cz>
Date: Sun, 04 Jan 2009 00:50:38 +0100
From: Martin MOKREJŠ <mmokrejs@...osome.natur.cuni.cz>
To: Duane Griffin <duaneg@...da.com>
CC: Pavel Machek <pavel@...e.cz>,
kernel list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>, tytso@....edu,
mtk.manpages@...il.com, rdunlap@...otime.net,
linux-doc@...r.kernel.org
Subject: Re: document ext3 requirements
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
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.
Sure that does not prevent my case when I let ext2 IFS writing onto
my ext3 partition. Actually, couldn't the driver at least warn me
the journal log is non-empty (am just a user, sorry, cannot check
myself the code at www.fs-driver.org if it could do at least this
although it does not understand ext3). ;-)
Martin
--
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