geom_vol_ffs problems

[Per Kristian Hove]

[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