Re: newfs and mount vs. half-baked disks

From: Wes Peters (wes_at_softweyr.com)
Date: 11/06/03

  • Next message: Kirk McKusick: "Re: >0x7fffffff blocksize filesystem reporting" 
    To: Peter Jeremy <PeterJeremy@optushome.com.au>, kirk@mckusick.com
Date: Thu, 6 Nov 2003 09:43:34 -0800

    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@softweyr.com

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Kirk McKusick: "Re: >0x7fffffff blocksize filesystem reporting"

    Relevant Pages