From:   Jim Mostek <mostek@sgi.com>
Message-Id: <200004051928.OAA19011@fsgi344.americas.sgi.com>
Subject: Re: XFS as Root filesystem
To:     lws@spinnakernet.com (Lyle Seaman)
Date:   Wed, 5 Apr 2000 14:28:19 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <38EB8FEF.9CB411C@spinnakernet.com> from "Lyle Seaman" at Apr 05, 2000 03:11:44 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hey Lyle, long time no read your typed words! Good to see your around.

Anyway, you are right that the way the file system gets into a state where
it needs to have recovery run is that it was mounted read/write (i.e. not
read-only).

Linux mounts the root, read-only, when it is coming up.
If XFS is the root file system (which was read-write) and the system crashed,
we need to run recovery before it can be mounted read-only.

As I said in an earlier mail, we should just be able to set a new flag on
the mount that says this is a special root mount and that we should run
recovery.

In xlog_recover() in xfs_log.c, we see:

                /*
                 * disallow recovery on read-only mounts.  note -- mount
                 * checks for ENOSPC and turns it into an intelligent
                 * error message.
                 */
                if (readonly)
                        return ENOSPC;


We could have a new flag passed to xlog_recover to override this and
allow recovery.

Jim

>
>>
>> > ext3 doesn't really "solve" this, but it does step around it: if you
>> > mount a filesystem which needs recovery as readonly, then it will
>> > warn you that it is enabling write access to the device temporarily
>> > and will perform the recovery.  The filesystem retains full ROFS
>> > protection, but the device does get written to.  Ext3 does a device
>> > check to make sure that the block device is writable before it
>> > attempts to do this, and if it is not, it will abort the mount
>> > entirely: you can't mount ext3 on readonly media if recovery is
>> > needed.
>> >
>> > --Stephen
>>
>> Just to report on where XFS is in all of this, it will fail a read only
>> mount request if it determines recovery needs to be run. We do have
>> a norecovery mount option - but this is really for internal use only,
>> I would not recommend using it.
>>
>
>How does a readonly filesystem become inconsistent?
>(esp: "how does ext3 on readonly media" become inconsistent?)
>
>The obvious answer is "well, it *wasn't* readonly when it
>became inconsistent".
>
>If that's the case, then why do you care?  Naively, I wouldn't
>think this is a big deal.  Why am I wrong?
>
>
>
>