geom_vinum platform-independent brokenness

[Damian Wiest]

On Fri, Mar 07, 2008 at 05:00:58PM -0600, Rick C. Petty wrote:
> Since no one seems to be working on fixing gvinum, I've decided to
> investigate and address some problems I have encountered recently.
> 
> ***
> 
> There is an incompatibility in geom_vinum with respect to i386/amd64.
> In particular, the following structure (in geom_vinum_var.h) is stored
> as-is on each disk (or provider):
> 
> 	struct gv_hdr {
>         	uint64_t        magic;
> 	#define GV_MAGIC        22322600044678729LL
> 	#define GV_NOMAGIC      22322600044678990LL
> 
>         	int             config_length;
>         	struct gv_label label;
> 	};
> 
> The problem is the "struct gv_label" is not aligned properly against the
> int.  On i386 and amd64 system, this corresponds to these offsets:
> 
> 	i386	amd64	field
> 	----	-----	-----
> 	0	0	magic
> 	8	8	config_length
> 	-	-	from struct gv_label :
> 	12	16	sysname
> 	44	48	name (of drive)
> 	76	80	date_of_birth
> 	84	96	last_update
> 	92	112	drive_size
> 	=	=
> 	100	120	= total header size
> 
> Because of this, someone who has volumes created with i386 gvinum cannot
> put those volumes onto an amd64 system, and vice-versa!

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

How is this scenario handled for basic disks?  Can an amd64 system 
handle a disk that was labeled on an x86 system?  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.

Aren't you going to run into issues with your filesystems when moving 
from one architecture to another that uses a different bus width?

-Damian