geom_vinum platform-independent brokenness

[Rick C. Petty]

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.

> 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.

> 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