From owner-freebsd-arch@FreeBSD.ORG Wed Nov 5 00:15:31 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 BCABD16A4CE for ; Wed, 5 Nov 2003 00:15:31 -0800 (PST) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD0EE43F85 for ; Wed, 5 Nov 2003 00:15:29 -0800 (PST) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])hA58FHf1038050; Wed, 5 Nov 2003 19:15:30 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost)hA58FGqx038049; Wed, 5 Nov 2003 19:15:16 +1100 (EST) (envelope-from jeremyp) Date: Wed, 5 Nov 2003 19:15:16 +1100 From: Peter Jeremy To: Wes Peters Message-ID: <20031105081516.GA38016@cirb503493.alcatel.com.au> References: <200311041737.20467.wes@softweyr.com> <20031105015709.GC28915@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031105015709.GC28915@dan.emsphone.com> User-Agent: Mutt/1.4.1i 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 08:15:31 -0000 On Tue, Nov 04, 2003 at 07:57:10PM -0600, Dan Nelson wrote: >In the last episode (Nov 04), Wes Peters said: >> 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). > >Would writing a block of zeros to the first (or first n) superblock, >newfs'ing, then rewriting the correct data do the same thing without >affecting the filesystem itself? I'm thinking about 4.x and cross-OS >portability here. My suggestion would be to write a non-standard magic number to fs_magic in the primary and first backup superblock (block 32) - I believe these are the only ones fsck will automatically search. The "invalid" magic number means that neither mount nor fsck will recognize the partition. Those two blocks can be re-written at the end - the additional time should be unnoticable. The remaining superblocks would appear valid but if someone is silly enough to manually specify a alternate superblock in an incompletely newfs'd filesystem, they get a neat hole in their foot. (A known non-standard magic number would also allow fsck to warn that the filesystem was incompletely newfs'd). I'm surprised that this bug hasn't been noticed previously. Peter