newfs and mount vs. half-baked disks

Kirk McKusick mckusick at
Fri Nov 7 23:30:04 PST 2003

> Date: Fri, 7 Nov 2003 22:01:21 +1100 (EST)
> From: Bruce Evans <bde at>
> To: Wes Peters <wes at>
> Cc: arch at
> Subject: Re: newfs and mount vs. half-baked disks
> X-ASK-Info: Whitelist match
> 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.

You cannot depend on the disk label as the disklabel is going away
or at least being wholly overhauled with GEOM. In particular, the
existing disk label only has a 2^32 block count which is insufficient
for filesystems larger than 2Tb.

> 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.
> Bruce

I concur that knocking out the magic number will have the benefit
of making all the existing utilities and kernels refuse to inspect /
mount the filesystem.

	Kirk McKusick

More information about the freebsd-arch mailing list