From owner-freebsd-arch@FreeBSD.ORG Sat Nov 8 00:35:35 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 B97FF16A4CE for ; Sat, 8 Nov 2003 00:35:35 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A57343FE0 for ; Sat, 8 Nov 2003 00:35:34 -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 TAA21631; Sat, 8 Nov 2003 19:35:17 +1100 Date: Sat, 8 Nov 2003 19:35:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <200311072348.hA7NmgaG000289@beastie.mckusick.com> Message-ID: <20031108191433.J608@gamplex.bde.org> References: <200311072348.hA7NmgaG000289@beastie.mckusick.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: Sat, 08 Nov 2003 08:35:35 -0000 On Fri, 7 Nov 2003, Kirk McKusick wrote: > > From: Bruce Evans > > ... > > 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. I don't use GEOM, so the label won't be going away for me. Anyway, there is no dependency (the label is just one of the things that one might examine to recover a crashed disk), and any overaul by GEOM would have to duplicate the functionality of storing metadata about the superblocks somewhere outside the superblocks. (I actually store metadata about file systems in (backups of) disk files in /var/backups. Normal backups provide inadequate backups of metadata.) The block count is in units of sector size, so disks much larger than 2TB can be supported by disklabel using (fake if necessary) sector sizes larger than 512. File systems need to use similarly large block (fragment for ffs) sizes, and some patches are needed for reading superblocks if the sector size is larger than 8K. Since ffs uses a block size of 16K by default, a sector size of 16K are not unreasonable and this is sufficent for disks smaller then 64TB. Bruce