newfs and mount vs. half-baked disks

Bruce Evans bde at
Wed Nov 5 03:18:57 PST 2003

On Tue, 4 Nov 2003, Wes Peters wrote:

> Upon switching to FreeBSD 5.x and disk-based hardware at ${DAYJOB}, we
> found a little problem.  We have a large data area on our disk that
> holds transient data; when the system boots if this filesystem isn't
> clean we just newfs and mount the clean new filesystem.
> The problem came when some wiseacre yanked the powercord in the middle
> of newfs'ing this 40GB filesystem.  When the system booted, it noted
> the filesystem as clean, mounted it, and promptly panic'ed on the first
> write access.  Oops.
> 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.  As an implementation detail, it
might be simpler to write 0's to the whole superblock than 0 to one
word in it.  I think writing special values to all the superblock
copies is not needed, since the kernel and utilities give up if they
don't find the magic number in the first superblock (not sure of this
for fsck_ffs).  OTOH, newfs should start by setting the magic number
to a non-ffs value in all of the (4) possible superblocks given by
SBLOCKSEARCH, since the superblock for the previous file system may
have been in a different place.

Newfs should also set the unclean flags and any related flags until it
is nearly finished, but that alone wouldn't work so well.  The kernel
would still permit readonly mounts, and fsck would be confused by
half-baked file systems.  I think permitting readonly mounts without
the force flag is a bug (we only require the force flag for r/w mounts
of unclean file systems).  Reading from a damaged file system may be
just as dangerous as writing.

> The attached patch does this, plus a bit more.  The fs_state field is

Nothing was attached :-).  I would probably prefer the version that does
a bit less.


More information about the freebsd-arch mailing list