Re: newfs and mount vs. half-baked disks

• Previous message: Bruce Evans: "Re: >0x7fffffff blocksize filesystem reporting"
• In reply to: Wes Peters: "Re: newfs and mount vs. half-baked disks"
• Next in thread: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
• Reply: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
• Reply: Wes Peters: "Re: newfs and mount vs. half-baked disks"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 7 Nov 2003 22:01:21 +1100 (EST)
To: Wes Peters <wes@softweyr.com>

On Thu, 6 Nov 2003, Wes Peters wrote:

> On Wednesday 05 November 2003 03:18, Bruce Evans wrote:
> > On Tue, 4 Nov 2003, Wes Peters wrote:
> > >
> > > 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).
> >
> > There is no need to use a new flag. Just set the magic number to a
> > value different from both FS_UFS1_MAGIC and FS_UFS2_MAGIC, e.g., to
> > 0, until newfs is nearly finished.
>
> I specifically don't want to do that because I want the state
> "interrupted newfs operation" to be discernable from the state
> "something stomped on your superblock." This I believe better shows
> that the superblock is valid but the filesystem is not (yet).

That's not a very useful distinction, especially for your application
where the disk contents is disposable and you re-newfs it a lot. After
a crash the complete state (as given by the disk contents) may be
almost anywhwere between its initial and final values, depending on
buffering etc., so it would be very difficult just to determine what
it is if you needed it.

Some cases can be discerned anyway, depending on how much erasing of
metadata newfs does when it starts. E.g., if there was an ffs file
system on the disk, then this will be recorded in the disk label unless
that feature has been axed). newfs doesn't rewrite the label until
just before it finishes, so the old label can be looked at to determine
what was there. Writing the label last may be a bug though. Perhaps
newfs should erase all the primary metadata for the old filesystem
when it starts so as to minimise the window where there may be
conflicting metadata.

Clearing the magic number works better because it requires no kernel
changes and no changes to applications other than ufs. In particular,
half-baked file systems formatted with the changed newfs work right
under all versions of FreeBSD (i.e., they don't work and don't cause
panics), and utilities like dumpfs and fsdb don't need to be changed
to display and/or edit the newly used field.

> The name fs_state suggests someone was thinking of recording some sort
> of state in here that was never implemented. I've simply used it to
> record states 'newfs operation completed' and 'newfs operation not
> completed.'

Its comment also suggests that it was for validating fs_clean. This
goes back to at least FreeBSD-1 where both fs_state and fs_clean are
unused. fs_clean wasn't used in 4.4BSD-Lite1 either. Use of it was
added in FreeBSD and/or NetBSD and picked up by Lite2. I am nervous
about using yet another variable for things related to state. There
is a large enough mess for fs_clean already. We now also have FS_UNCLEAN
in fs_flags (which were also unused until relatively recently). As I
understand it (the details were simpler when I understood them all),
FS_UNCLEAN was originally fs_clean done right except it probably belongs
in fs_state. It was just fs_clean inverted and put in a bitmap. Now
FS_UNCLEAN is tangled up with FS_NEEDSFSCK and is not simply fs_clean
inverted.

Bruce
_______________________________________________
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"

• Previous message: Bruce Evans: "Re: >0x7fffffff blocksize filesystem reporting"
• In reply to: Wes Peters: "Re: newfs and mount vs. half-baked disks"
• Next in thread: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
• Reply: Kirk McKusick: "Re: newfs and mount vs. half-baked disks"
• Reply: Wes Peters: "Re: newfs and mount vs. half-baked disks"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]