From owner-freebsd-current@FreeBSD.ORG Fri Jun 6 13:40:38 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D83337B401 for ; Fri, 6 Jun 2003 13:40:38 -0700 (PDT) Received: from abel.math.ntnu.no (abel.math.ntnu.no [129.241.15.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 4611443F93 for ; Fri, 6 Jun 2003 13:40:34 -0700 (PDT) (envelope-from perhov@math.ntnu.no) Received: (qmail 1873 invoked by uid 29119); 6 Jun 2003 20:40:32 -0000 Date: Fri, 6 Jun 2003 22:40:32 +0200 (MEST) From: Per Kristian Hove To: Gordon Tetlow In-Reply-To: <20030606182001.GJ691@roark.gnf.org> Message-ID: References: <20030606182001.GJ691@roark.gnf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: geom_vol_ffs problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2003 20:40:38 -0000 [Gordon Tetlow, 2003-06-06] | Thanks for doing this analysis. I've run into the same thing here at | work but I just haven't had any time to debug it. I'll see if I can | work something up that'll address this problem. Given that it should be OK to have a file system smaller than the partition (say, if you've copied it byte-for-byte to a larger disk and plan to growfs it later, and your fstab contains /dev/vol entries) the obvious thing would be to check the "parent" GEOM and check that the partition we're tasting is of type FS_BSDFFS. That would eliminate the "c"-partition problem. I think it also should be OK to create a file system on top of a non-BSD-labeled device - in which case there's no FS_BSDFFS to check for. In this case there's no problem with "a" and "c" partitions, so you will "usually" succeed on all partitions that start with the correct UFS magic. (You'd still like to succeed even if the file system is smaller than the underlying device). However, if the parent GEOM is a GEOM_SUN, we're in trouble again. Slice 2 in a sunlabel is usually equivalent to the "c" partition in a bsdlabel. It seems to me that the most robust solution would be to require both that a) pp->mediasize >= fs->fs_old_size * fs->fs_fsize (and do not require the file system to fill the partition) and also that b) the parent geom has to be of a known, explicitly allowed type. Don't let geom_vol_ffs create a provider unless it knows how to handle the parent geom. Then teach geom_vol_ffs that it's OK to succeed if any single one of the following conditions are met: - parent geom is a BSD _and_ the partition type is FS_BSDFFS - parent geom is an MBR - parent geom is a DISK geom (whole disk, e.g. da0) - parent geom is a sunlabel _and_ the slice number is not 2 etcetera. One more problem: what about mirrored ccd devices? If ccd0 is a mirror of da0s1a and da1s1a, geom_vol_ffs should attach to the mirror (ccd0 or ccd0a, etc.) and not to one of the sides (da0s1a or da1s1a). Is it at all possible to require that also - parent geom does NOT have any consumers of type ccd (etc.) attached to its provider. or is that hard to check? (I really don't know enough about GEOM to have an opinion on how it should be done, I just have ideas of how I'd like it to work). -- Per Kristian Hove Dept. of Mathematical Sciences Norwegian University of Science and Technology