lkml.org 
[lkml]   [2007]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Add a norecovery option to ext3/4?
Phillip Susi wrote:
> Eric Sandeen wrote:
>> It means the filesystem should not be writeable when it is mounted.
>> This is not the same as saying that the filesystem itself should do no
>> IO in the course of making that read-only mount available.
>
> I disagree.
>
>> I respectfully disagree, see above.
>
> Based on what? I argue that historically the primary use of the read
> only mount flag was to prevent the underlying filesystem from being
> modified and possibly damaged further before it can be fsck'ed. It
> became common practice to mount the root filesystem read only and run a
> fsck on it, then either reboot or remount read-write depending on if
> fsck had to make changes.

except in the case of a journaling filesystem, where the journal in
theory obviates the need for a fsck. (yes, I know... fsck still has a
place...) But, fsck is largely meaningless until the journal has been
recovered anyway (fs can only be consistent if it includes uncommited
transactions in the journal), so isn't this new territory?

I guess looking to the man page for clarification of intent is no help...

ro Mount the file system read-only.


> In this context, the meaning of the read only mount flag was clear: do
> not write to the disk. If you wish to redefine it as "do not allow me
> write access to any files" then you fly in the face of convention, and
> the onus is on you to provide a compelling argument to make such a change.

I'm admittedly playing devil's advocate here :) but what, in the
historical non-journalled filesystem case, would be writing to the
device anyway, if all IO from the vfs were stopped? Without the
journal, isn't vfs-ro the same as bdev-ro, largely?

As a counter example, if you had a filesystem which saves it's last
mount time in the superblock; should a ro mount not update that time?
(perhaps not, depending on how that timestamp was intended to be used.)

>> In that case you are mounting the same filesystem uner 2 different
>> operating systems simultaneously, which is, and always has been, a
>> recipe for disaster. Flagging the fs as "mounted already" would
>> probably be a better solution, though it's harder than it sounds at
>> first glance.
>
> No, it has not been. Prior to poorly behaved journal playback, it was
> perfectly safe to mount a filesystem read only even if it was mounted
> read-write by another system ( possibly fsck or defrag ). You might not
> read the correct data from it, but you would not damage the underlying
> data simply by mounting it read-only.

You might not damage the underlying filesystem, but you could sure go
off in the weeds trying to read it, if you stumbled upon some
half-updated metadata... so while it may be safe for the filesystem, I'm
not convinced that it's safe for the host reading the filesystem.

>> Under all conditions it should be safe to mount a read-only block
>> device, but that is not the same as mounting a filesystem read-only.
>
> Historically it was the same thing. I see no reason to change that
> behavior, do you?

but it's already changed, and has been in linux since ext3 came on the
scene. mount -o ro -does- replay the journal. Surely readonly does not
imply that we want a corrupted filesystem if it was not cleanly shut
down. I suppose there is a place for the argument that a readonly mount
of a journaled filesystem -should- present a recovered filesystem to the
user, without actually recovering the log to disk. I guess to me, it
hardly seems worth the effort, as the precedent is long set for doing
recovery on a read-only mount.

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-10 21:23    [W:0.239 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site