Re: Journaling: Surviving or allowing unclean shutdown?

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On Thu, Jan 04, 2001 at 10:08:21PM +0100, Stefan Traby wrote:
> On Thu, Jan 04, 2001 at 07:21:04PM +0000, Stephen C. Tweedie wrote:
> 
> > ext3 does the recovery automatically during mount(8), so user space
> > will never see an unrecovered filesystem.  (There are filesystem flags
> > set by the journal code to make sure that an unrecovered filesystem
> > never gets mounted by a kernel which doesn't know how to do the
> > appropriate recovery.)
> 
> I did not follow the ext3 development recently, how did you solve
> the "read-only mount(2) (optionally on write protected media)" issue ?
> 
> Does the mount fail, or does the code virtually replays (without writing)
> only ?

The code currently checks if the underlying media is write-protected.
If it is, it fails the mount; if not, it does the replay (so that
mounting a root fs readonly works correctly).

I will be adding support for virtual replay for root filesystems to
act as a last-chance way of recovering if you really cannot write to
the root, but journaling filesystems really do expect to be able to
write to the media so I am not sure whether it makes sense to support
this on non-root filesystems too.

> I think any other action (only replaying on rw mount and presenting
> a broken filesystem on ro) is quite fatal, at least if I think of
> a replay on -remount,rw :)

Correct.

> Also, an unconditional hidden replay even if "ro" is specified is not nice.

> This is especially critical on root filesystem

In what way?  A root fs readonly mount is usually designed to prevent
the filesystem from being stomped on during the initial boot so that
fsck can run without the filesystem being volatile.  That's the only
reason for the readonly mount: to allow recovery before we enable
writes.  With ext3, that recovery is done in the kernel, so doing that
recovery during mount makes perfect sense even if the user is mounting
root readonly.

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