From owner-freebsd-current@FreeBSD.ORG Sat Jun 7 04:33:43 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 6E5BC37B401 for ; Sat, 7 Jun 2003 04:33:43 -0700 (PDT) Received: from abel.math.ntnu.no (abel.math.ntnu.no [129.241.15.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 197B543FAF for ; Sat, 7 Jun 2003 04:33:42 -0700 (PDT) (envelope-from perhov@math.ntnu.no) Received: (qmail 24840 invoked by uid 29119); 7 Jun 2003 11:33:40 -0000 Date: Sat, 7 Jun 2003 13:33:40 +0200 (MEST) From: Per Kristian Hove To: Poul-Henning Kamp In-Reply-To: <87296.1054977860@critter.freebsd.dk> Message-ID: References: <87296.1054977860@critter.freebsd.dk> 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: Sat, 07 Jun 2003 11:33:43 -0000 [Poul-Henning Kamp, 2003-06-07] | This does not work for FFS filesystems stored in apple or sun partitions, | but theese do on the other hand, not have the magic 'c' problem. (I know it wouldn't work for FFS filesystems in non-BSD partitions, which must be supported. It was not my suggestion for a solution, it was the beginning of a chain of thought leading to this:) Sun partitions _do_ have a magic slice (slice 2), so I think geom_vol_ffs needs to know which types of providers it can and cannot attach to. Other not-yet-invented GEOMs may behave like sunlabels and bsdlabels do (have a "magic" slice/a slice overlapping its other slices), so geom_vol_ffs should have a list of explicitly allowed types of providers it can attach to: - 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 (either check for number=2 or tag="backup") - parent geom is an apple geom - parent geom is a gpt and its type is GPT_ENT_TYPE_FREEBSD_UFS - ... It should probably also know how to avoid connecting to a submirror in a mirror instead of the mirror and stuff like that. That also requires knowledge of the state of its parent. To be sure that geom_vol_ffs doesn't do the wrong thing (it should be reliable enough to be used in fstab), that check should perhaps be: - parent geom doesn't have geoms of any other type than: [explicit list, for the time being only "dev"] attached to it. so that adding new classes of GEOMs (GEOM_RAID5?) won't break geom_vol_ffs, but they may require geom_vol_ffs to be aware of them in order to have geom_vol_ffs working for those new classes. I'd really like geom_vol_ffs to be deterministic enough to be used in fstab. -- Per Kristian Hove Dept. of Mathematical Sciences Norwegian University of Science and Technology