Re: newfs and mount vs. half-baked disks

• Previous message: Brian F. Feldman: "Re: my 802.11 work"
• In reply to: Peter Jeremy: "Re: newfs and mount vs. half-baked disks"
• Next in thread: Gordon Tetlow: "Re: newfs and mount vs. half-baked disks"
• Reply: Gordon Tetlow: "Re: newfs and mount vs. half-baked disks"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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"

• text/x-diff attachment: fs_state.patch

• Previous message: Brian F. Feldman: "Re: my 802.11 work"
• In reply to: Peter Jeremy: "Re: newfs and mount vs. half-baked disks"
• Next in thread: Gordon Tetlow: "Re: newfs and mount vs. half-baked disks"
• Reply: Gordon Tetlow: "Re: newfs and mount vs. half-baked disks"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]