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
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
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.
We could have a new flag passed to xlog_recover to override this and
>> > 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
>If that's the case, then why do you care? Naively, I wouldn't
>think this is a big deal. Why am I wrong?