newfs and mount vs. half-baked disks
wes at softweyr.com
Thu Nov 6 09:43:40 PST 2003
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...
Size: 4974 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20031106/ca22f0f3/fs_state.bin
More information about the freebsd-arch