newfs and mount vs. half-baked disks

[Wes Peters]

On Friday 07 November 2003 03:01 am, Bruce Evans wrote:
> On Thu, 6 Nov 2003, Wes Peters wrote:
> > On Wednesday 05 November 2003 03:18, Bruce Evans wrote:
> > > On Tue, 4 Nov 2003, Wes Peters wrote:
> > > > I emailed Kirk about this state of affairs and he confirmed that
> > > > newfs was developed with operator intervention in mind.  He
> > > > suggested employing one of the unused flags in the filesystem
> > > > header as a 'consistent' flag, setting it to 'not consistent' at
> > > > the beginning of newfs, and then updating to 'is consistent' at
> > > > the end.  The performance hit in updating all superblock copies
> > > > at the end is small but noticable (< 1s on a rather slow 6GB
> > > > filesystem).
> > >
> > > There is no need to use a new flag.  Just set the magic number to a
> > > value different from both FS_UFS1_MAGIC and FS_UFS2_MAGIC, e.g., to
> > > 0, until newfs is nearly finished.
> >
> > I specifically don't want to do that because I want the state
> > "interrupted newfs operation" to be discernable from the state
> > "something stomped on your superblock."  This I believe better shows
> > that the superblock is valid but the filesystem is not (yet).
>
> That's not a very useful distinction, especially for your application
> where the disk contents is disposable and you re-newfs it a lot. 

Oh, but after the newfs we take different actions depending on whether we 
think we're creating a new filesystem or restoring an old one.  In 
particular, if we are restoring a previous filesystem, there are 
references to restored data that need to be checked for validity.  None 
of these references exist on a new system, so we can avoid the cost of 
searching for them.

> After
> a crash the complete state (as given by the disk contents) may be
> almost anywhwere between its initial and final values, depending on
> buffering etc., so it would be very difficult just to determine what
> it is if you needed it.
>
> Some cases can be discerned anyway, depending on how much erasing of
> metadata newfs does when it starts.  E.g., if there was an ffs file
> system on the disk, then this will be recorded in the disk label unless
> that feature has been axed).  newfs doesn't rewrite the label until
> just before it finishes, so the old label can be looked at to determine
> what was there.  Writing the label last may be a bug though.  Perhaps
> newfs should erase all the primary metadata for the old filesystem
> when it starts so as to minimise the window where there may be
> conflicting metadata.
>
> Clearing the magic number works better because it requires no kernel
> changes and no changes to applications other than ufs.  In particular,
> half-baked file systems formatted with the changed newfs work right
> under all versions of FreeBSD (i.e., they don't work and don't cause
> panics), and utilities like dumpfs and fsdb don't need to be changed
> to display and/or edit the newly used field.

Actually, changing the magic number to a differing non-zero magic value 
has all the benefits you suggest, plus the benefit of signifying what I'm 
looking for (except for a tiny window of vulnerability where a disk 
*could* have the alternate magic number written in the superblock 
location by chance.)

> > The name fs_state suggests someone was thinking of recording some
> > sort of state in here that was never implemented.  I've simply used
> > it to record states 'newfs operation completed' and 'newfs operation
> > not completed.'
>
> Its comment also suggests that it was for validating fs_clean.  This
> goes back to at least FreeBSD-1 where both fs_state and fs_clean are
> unused.  fs_clean wasn't used in 4.4BSD-Lite1 either.  Use of it was
> added in FreeBSD and/or NetBSD and picked up by Lite2.  I am nervous
> about using yet another variable for things related to state.  There
> is a large enough mess for fs_clean already.  We now also have
> FS_UNCLEAN in fs_flags (which were also unused until relatively
> recently).  As I understand it (the details were simpler when I
> understood them all), FS_UNCLEAN was originally fs_clean done right
> except it probably belongs in fs_state.  It was just fs_clean inverted
> and put in a bitmap.  Now FS_UNCLEAN is tangled up with FS_NEEDSFSCK
> and is not simply fs_clean inverted.

Yes, trying to understand the interactions of fs_state and FS_UNCLEAN made 
my head hurt.  Badly.  I'll do a bit of testing with the alternate magic 
number and report what I observe, but probably not until Monday.  I left 
my testing disk at work and I have too much sysadmin work at home to work 
on code this weekend.  Sigh.

-- 

        Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes at softweyr.com