geom_vinum platform-independent brokenness

[Damian Wiest]

On Sat, Mar 08, 2008 at 12:44:55AM -0600, Rick C. Petty wrote:
> On Fri, Mar 07, 2008 at 08:49:54PM -0600, Damian Wiest wrote:
> > 
> > So you're saying that you should be able to remove a disk (or set of disks)
> > from an x86 system, install it in a system running the amd64 release and
> > have things just work?
> 
> That is the plan.  At work, we have a couple of machines on which we wanted
> to try amd64, but couldn't boot since the root fs is in gvinum.  It makes
> sense for people who want perhaps to dual boot or otherwise want to migrate
> their data.
> 
> > I would imagine that most people would simply use 
> > dump/restore, but I agree that it would be nice if one didn't have to do
> > this.
> 
> That solution obviously requires twice the disk space.  It's especially
> worse if you're using RAID5.  At home I'm considering upgrading to amd64
> (since it's only a file server), but I don't have 4 TB of spare disks lying
> around for the migration.
> 

> > How is this scenario handled for basic disks?
> 
> I'm not sure I understand your question.

I was just thinking of the simplest case where the disk you're moving 
used a bsdlabel.

> > Can an amd64 system 
> > handle a disk that was labeled on an x86 system?
> 
> No, that was exactly the problem I am describing.  It noticed that there
> were vinum disks, but the configuration was all screwed up.
> 
> > I haven't ever tried 
> > this, but the manpage for bsdlabel suggests that it won't work unless 
> > you originally wrote an amd64 label by using the -m option.
> 
> 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.

> > Aren't you going to run into issues with your filesystems when moving 
> > from one architecture to another that uses a different bus width?
> 
> How so?  Are you saying there are bugs in UFS which will prevent this from
> working?  If so, this is a much bigger problem than I anticipated.  Looking
> at sys/ufs/ffs/fs.h, I do see a bunch of pointers in the superblock
> structure ("struct fs"), but all other superblock fields and other on-disk
> structures have fixed size values.  Also there's a sanity test on the size
> of the "struct fs".  Someone clearly has thought of this problem
> (McKusick ?).  After some minimal testing of mounting i386-created UFS2
> volumes on amd64, everything seems to work just fine.
> 
> I've also investigated geom_mirror, and the on-disk structure seems clean.
> There may be others that are broken, but geom_vinum is what I've noticed
> and that is what I intend to fix.  If UFS *is* broken, it should be fixed
> also.
> 
> Thank you for reminding me to test the filesystem!
> 
> -- Rick C. Petty

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.

-Damian