Bug 242690

Adding Dave T. to the cc list to get his input as per last week's
cluster meeting.

It seems that e2fstools has a thing called libblkid which can (amoung other
things) read GFS/GFS2 labels already. Maybe we can use that rather than invent
our own? It also has its own private copy of the GFS and GFS2 sb structures, so
if we do UUID too (and I think we should) then we'll need to make a note to
update that too.

OK, I'll try to explain the whole picture here.

An ext3 fs can have a LABEL or a UUID.  Both of them are strings 16 characters
long that are stored in the superblock.  They can be set via mkfs or tune2fs. 
They are alternative ways to do the same thing.  What they do is provide a way
to mount a device without specifying the device name.

So, if you mkfs -L foo /dev/sdb1, you can then mount this new fs in two ways:
1) mount /dev/sdb1 /mnt
2) mount -L foo /mnt

UUID's are the same, you mkfs /dev/sdb1; tune2fs -U 123-456-789 /dev/sdb1,
you can then mount this new fs in two ways:
1) mount /dev/sdb1 /mnt
2) mount -U 123-456-789 /mnt

The way mount -L and mount -U work is that mount(8) scans all the devices it
can find, reads the header off each one (using libvolume_id or libblkid),
and if it finds one with a matching label or uuid, mounts it.  LABELs tend
to be used on local machines to mount things like /boot, but don't work
well in SAN settings where it would be easy to have duplicate names, so the
uniqueness of UUIDs works better (but you lose the ease of having a readable
name).

A gfs fs has a NAME, which combines the best of both LABEL and UUID -- it's a
readable name, _and_ is guaranteed to be unique in a SAN setting.  It can
be used for _exactly_ the same thing as LABEL and UUID can for ext3.

You mkfs -t foo:bar /dev/sdb1, then you can mount this new fs in three ways:
1) mount /dev/sdb1 /mnt
2) mount -L foo:bar /mnt
3) mount -U foo:bar /mnt

Our NAME is already _both_ a LABEL _and_ a UUID, we don't need to add
_anything_ to gfs.  The only thing we need to do to make mount -L/-U work
with gfs is add a couple lines to libvolume_id to copy the NAME from the gfs
superblock (sb_locktable) into both the label and uuid fields of the volume_id
struct.

The limitation is that the LABEL and UUID strings in mount/volume_id/blkid are
at most 16 characters long.  Our NAME can be up to 64 characters long.  Most
people use a NAME that's well under 16 characters anyway.  It would be
appropriate to mention in the mkfs.gfs man page that a NAME over 16 characters
won't work with the -L/-U mount options.

I'm quite happy with using the name as the fs label and thats what libblkid
seems to do anyway. I do think that it would be useful to have a UUID though in
addition, even if only for compatibility purposes with other filesystems. It
does serve a useful purpose in case someone does set two fs up with the same
name though.

I don't think the UUID thing is at the top of the priority list right now
though, so if we land up just making mount work with labels being the existing
name in the mean time, I'm more than happy with that.

What kind of compatibility with other fs's are you refering to?
What purpose would a uuid serve if someone gives two fs's the same name?
What would the addition of a uuid give us that we don't already have?

The UUID is a 16 byte opaque binary blob. Its designed to be supplied automatically by mkfs rather than being under the control of the user. That makes it rather more tricky for someone to land up with two filesystems with the same UUID than with identical labels.

The plan is to add a UUID field to the GFS2 sb so that we can support that, and to continue using our name as the label (which, by contrast, is supposed to be a readable string and also assigned by the user).

At that point we can then support both the -U and -L mount options, just like other filesystems. As pointed out in comment #3, we do need to document the length restriction of labels vs. our names.

Patches posted to cluster-devel