geom_vinum platform-independent brokenness

[Rick C. Petty]

On Wed, Mar 12, 2008 at 07:12:32PM -0500, Damian Wiest wrote:
> 
> I was just thinking of the simplest case where the disk you're moving 
> used a bsdlabel.

Ok.

> > I'm not talking about the disklabel here.  geom_vinum takes up the first
> > 265 sectors (512 bytes each) to store its configuration.  These are
> > straight-up disks that aren't needed in Windoze or other OS-- just plain
> > FreeBSD, so we use the full disks without labels or MBR partitions.
> 
> Right.  I was just wondering what would need to be changed when moving
> a bsdlabeled disk from x86 to amd64 or vice-versa.  I was thinking that 
> if the labels (both bsdlabel and gvinum's) were padded a bit at the end 
> (so you don't clobber any real data), then one could simply rewrite the 
> label once the disk was moved to the new system.  My thinking was that
> it might be simpler to allow the label to be rewritten with some utility 
> versus modifying how gvinum interprets labels.

geom_vinum has nothing to do with bsdlabels.  There is extra padding at the
beginning of the vinum configuration to allow for an MBR and/or a bsdlabel.
Because gvinum uses GEOM's tasting, all providers are searched for vinum
configuration..  It shouldn't matter whether you have a bsdlabel or not;
geom_vinum just seeks to byte 4096 into each provider and checks for the
magic.

> No, I wasn't saying anything about UFS in particular.  Just that you'll 
> also want to consider the underlying filesystems and not just the gvinum 
> bits.

*My* concern is the gvinum bits.  UFS seems to work for me, other file
systems are beyond the scope of this personal project.

-- Rick C. Petty