newfs and mount vs. half-baked disks

[Wes Peters]

Upon switching to FreeBSD 5.x and disk-based hardware at ${DAYJOB}, we 
found a little problem.  We have a large data area on our disk that 
holds transient data; when the system boots if this filesystem isn't 
clean we just newfs and mount the clean new filesystem.

The problem came when some wiseacre yanked the powercord in the middle 
of newfs'ing this 40GB filesystem.  When the system booted, it noted 
the filesystem as clean, mounted it, and promptly panic'ed on the first 
write access.  Oops.

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).

The attached patch does this, plus a bit more.  The fs_state field is 
used to signify the filesystem has been completely written.  The mount 
vfsop has been modified to require this field to be zero.  Newfs has 
been modified to initially set this field to a non-zero value until the 
last phase of superblock updates, when it is again cleared to zero.

The patch attached also adds testing code to newfs to force it to 
abandon the newfs operation in various places, to facilitate testing.  
This would obviously be committed in a separate commit, if at all.

Questions:

I'd like to commit the safer newfs and vfs support before 5.2.  Anyone 
have heartburn with that?  If so, would it be acceptable to make the 
extra I/O enabled by a command line option?  (I.e. skipping the first 
sbwrite and calling the second non-recursive, along with NOT muddying 
the fs_state and fs_clean flags.)

Should extra debugging code like this be committed?  Code like this 
would make it much easier to wrap a regression test around newfs, at 
the cost of introducing non-operational command line arguments into 
utilities.  If anyone has suggestions on how to do this, please share.

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

Wes Peters                                              wes at softweyr.com