[Top] [All Lists]

Re: XFS as Root filesystem

To: Lyle Seaman <lws@xxxxxxxxxxxxxxxx>
Subject: Re: XFS as Root filesystem
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 05 Apr 2000 14:23:15 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Lyle Seaman <lws@xxxxxxxxxxxxxxxx> of "Wed, 05 Apr 2000 15:11:44 EDT." <38EB8FEF.9CB411C@xxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
> >
> > > 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?

Should XFS (or another logging filesystem) detect that it needs to reply
the log then you really do not know what state the disk is in. XFS first 
writes meta-data to the log, and when it knows this is on disk it allows
the actual on disk meta-data to be written to. The writes to the log are
in the form of transactional changes to the disk structure (e.g. remove
a block from the free space structures and put it in a file, or initialize
an inode and put it in a directory). Say the log write went to disk and
we started doing the meta-data writes, we managed to put the entry in the
directory, but we did not update the inode with the correct information.

If you crash at this point and do not run recovery then you end up with
a directory entry pointing off into la la land - so read only behavior can
be broken.

To complete the picture, recovery consists of reading the log and replaying
it blindly into the meta-data (well semi-blindly, there are complications).


<Prev in Thread] Current Thread [Next in Thread>