From owner-freebsd-arch@FreeBSD.ORG Fri Nov 7 23:30:04 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 C31B316A4CE for ; Fri, 7 Nov 2003 23:30:04 -0800 (PST) Received: from beastie.mckusick.com (64118101118.sierratel.com [64.118.101.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1F7043FBD for ; Fri, 7 Nov 2003 23:30:02 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id hA7NmgaG000289; Fri, 7 Nov 2003 15:48:42 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200311072348.hA7NmgaG000289@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Fri, 07 Nov 2003 22:01:21 +1100." <20031107211239.O3343@gamplex.bde.org> Date: Fri, 07 Nov 2003 15:48:42 -0800 From: Kirk McKusick 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: Sat, 08 Nov 2003 07:30:04 -0000 > Date: Fri, 7 Nov 2003 22:01:21 +1100 (EST) > From: Bruce Evans > To: Wes Peters > Cc: arch@freebsd.org > Subject: Re: newfs and mount vs. half-baked disks > X-ASK-Info: Whitelist match > > That's not a very useful distinction, especially for your application > where the disk contents is disposable and you re-newfs it a lot. After > a crash the complete state (as given by the disk contents) may be > almost anywhwere between its initial and final values, depending on > buffering etc., so it would be very difficult just to determine what > it is if you needed it. > > Some cases can be discerned anyway, depending on how much erasing of > metadata newfs does when it starts. E.g., if there was an ffs file > system on the disk, then this will be recorded in the disk label unless > that feature has been axed). newfs doesn't rewrite the label until > just before it finishes, so the old label can be looked at to determine > what was there. Writing the label last may be a bug though. Perhaps > newfs should erase all the primary metadata for the old filesystem > when it starts so as to minimise the window where there may be > conflicting metadata. You cannot depend on the disk label as the disklabel is going away or at least being wholly overhauled with GEOM. In particular, the existing disk label only has a 2^32 block count which is insufficient for filesystems larger than 2Tb. > Clearing the magic number works better because it requires no kernel > changes and no changes to applications other than ufs. In particular, > half-baked file systems formatted with the changed newfs work right > under all versions of FreeBSD (i.e., they don't work and don't cause > panics), and utilities like dumpfs and fsdb don't need to be changed > to display and/or edit the newly used field. > > Bruce I concur that knocking out the magic number will have the benefit of making all the existing utilities and kernels refuse to inspect / mount the filesystem. Kirk McKusick