newfs and mount vs. half-baked disks

[Wes Peters]

On Wednesday 05 November 2003 00:15, Peter Jeremy wrote:
> On Tue, Nov 04, 2003 at 07:57:10PM -0600, Dan Nelson wrote:
> >In the last episode (Nov 04), Wes Peters said:
> >> 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).
> >
> >Would writing a block of zeros to the first (or first n) superblock,
> >newfs'ing, then rewriting the correct data do the same thing without
> >affecting the filesystem itself?  I'm thinking about 4.x and
> > cross-OS portability here.
>
> My suggestion would be to write a non-standard magic number to
> fs_magic in the primary and first backup superblock (block 32) - I
> believe these are the only ones fsck will automatically search.  The
> "invalid" magic number means that neither mount nor fsck will
> recognize the partition.  Those two blocks can be re-written at the
> end - the additional time should be unnoticable.  The remaining
> superblocks would appear valid but if someone is silly enough to
> manually specify a alternate superblock in an incompletely newfs'd
> filesystem, they get a neat hole in their foot.  (A known
> non-standard magic number would also allow fsck to warn that the
> filesystem was incompletely newfs'd).
>
> I'm surprised that this bug hasn't been noticed previously.

I found an unused field called "fs_state" and used that, as Kirk 
suggested.  Here's the new patch, which changes fsck to notice the 
fs_state and doesn't require re-writing all of the superblocks.

This patch adds a -E (generate errors) option to fsck, causing fsck to 
exit at various stages or to otherwise leave the state of fs_state and 
fs_clean in other than pristine conditions.  I will, of course, commit 
the -E changes separately from the fs_state changes.

Thanks in advance for reviewing.  And yes, I did manage to attach the 
patch this time.  Doh!

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

Wes Peters                                              wes at softweyr.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fs_state.patch
Type: text/x-diff
Size: 4974 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20031106/ca22f0f3/fs_state.bin