newfs and mount vs. half-baked disks

• Previous message: John Baldwin: "Re: HEADSUP: New i386 interrupt and SMP code.."
• Next in thread: Dan Nelson: "Re: newfs and mount vs. half-baked disks"
• Reply: Dan Nelson: "Re: newfs and mount vs. half-baked disks"
• Reply: Garance A Drosihn: "Re: newfs and mount vs. half-baked disks"
• Reply: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: arch@freebsd.org
Date: Tue, 4 Nov 2003 17:37:20 -0800

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

The attached patch does this, plus a bit more. The fs_state field is
used to signify the filesystem has been completely written. The mount
vfsop has been modified to require this field to be zero. Newfs has
been modified to initially set this field to a non-zero value until the
last phase of superblock updates, when it is again cleared to zero.

The patch attached also adds testing code to newfs to force it to
abandon the newfs operation in various places, to facilitate testing.
This would obviously be committed in a separate commit, if at all.

Questions:

I'd like to commit the safer newfs and vfs support before 5.2. Anyone
have heartburn with that? If so, would it be acceptable to make the
extra I/O enabled by a command line option? (I.e. skipping the first
sbwrite and calling the second non-recursive, along with NOT muddying
the fs_state and fs_clean flags.)

Should extra debugging code like this be committed? Code like this
would make it much easier to wrap a regression test around newfs, at
the cost of introducing non-operational command line arguments into
utilities. If anyone has suggestions on how to do this, please share.

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

• Previous message: John Baldwin: "Re: HEADSUP: New i386 interrupt and SMP code.."
• Next in thread: Dan Nelson: "Re: newfs and mount vs. half-baked disks"
• Reply: Dan Nelson: "Re: newfs and mount vs. half-baked disks"
• Reply: Garance A Drosihn: "Re: newfs and mount vs. half-baked disks"
• Reply: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]