cvs commit: src/sys/amd64/conf GENERIC src/sys/i386/conf GENERIC src/sys/ia64/conf GENERIC src/sys/pc98/conf GENERIC src/sys/powerpc/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/sun4v/conf GENERIC

[mjacob at freebsd.org]

>
>
> I prefer that last option. Uniquify them somehow, and perhaps spit a warning
> out to console. "LABEL: ufs/xxxx on device ad4s1b renamed to ufs/xxxx1".
> Maybe just force it to auto-increment that last number until it finds an
> available slot. If it can't find an available slot, then spit out an error
> about ambiguous GEOM labels....

This is exactly what I did for the g_multipath stuff.

There is *some* notion of UUID in most of the GEOM label types- I did it 
as a more explicit real UUID, but the crux of the biscuit is what is the 
real unique id?

Ascii names are useful, but they aren't usually veru unique. How many 
"oracle" labels will people pick? The choice I made is that the UUID is 
the *real* id. The ascii name is a 'convenience' name. If in a multipath 
or shared SAN environment, there is an ascii name collision during the 
taste operation, you can and do still build the geom but have to frob 
the name. Any kind of frob is okay because any automount using the ascii 
name is now going to fail.

An alternative is to export the UUID as a name, which is probably the 
right thing to do also.

This, btw, has come up for years (since RedHat 9) in Linux. The 
installer will pick "/boot" and "/" as the LABEL= qualifiers, which is a 
complete lose in a SAN or even in a multiboot non-shared environment, so 
I invariably change the LABEL= to UUID= qualifiers in both grub.conf and 
/etc/fstab.

-matt