From owner-freebsd-arch@FreeBSD.ORG Tue Nov 4 17:37:23 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 5718B16A4D0 for ; Tue, 4 Nov 2003 17:37:23 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65D3043FF3 for ; Tue, 4 Nov 2003 17:37:22 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id B4CB05B6FC for ; Tue, 4 Nov 2003 17:31:28 -0800 (PST) From: Wes Peters Organization: Softweyr.com To: arch@freebsd.org Date: Tue, 4 Nov 2003 17:37:20 -0800 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311041737.20467.wes@softweyr.com> Subject: 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 01:37:23 -0000 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