Date: Sat, 7 Jun 2003 13:33:40 +0200 (MEST) From: Per Kristian Hove <Per.Hove@math.ntnu.no> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-current@freebsd.org Subject: Re: geom_vol_ffs problems Message-ID: <Pine.GSO.4.52.0306071257050.17588@abel.math.ntnu.no> In-Reply-To: <87296.1054977860@critter.freebsd.dk> References: <87296.1054977860@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.52.0306071257050.17588>