From owner-freebsd-arch@FreeBSD.ORG Wed Nov 5 03:18:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 709DA16A4CE for ; Wed, 5 Nov 2003 03:18:57 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F0543FDD for ; Wed, 5 Nov 2003 03:18:56 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id WAA26417; Wed, 5 Nov 2003 22:18:49 +1100 Date: Wed, 5 Nov 2003 22:18:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Wes Peters In-Reply-To: <200311041737.20467.wes@softweyr.com> Message-ID: <20031105213950.Y1738@gamplex.bde.org> References: <200311041737.20467.wes@softweyr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2003 11:18:57 -0000 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. Bruce