|Summary:||GFS2 requires support for fs labels & UUIDs (tools)|
|Product:||[Fedora] Fedora||Reporter:||Steve Whitehouse <swhiteho>|
|Component:||gfs2-utils||Assignee:||Steve Whitehouse <swhiteho>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||rawhide||CC:||poelstra, swhiteho, teigland|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-12-17 10:10:22 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||242689|
Description Steve Whitehouse 2007-06-05 13:38:10 UTC
This is the userland tools part of the bug.
Comment 1 Robert Peterson 2007-06-18 22:57:17 UTC
Adding Dave T. to the cc list to get his input as per last week's cluster meeting.
Comment 2 Steve Whitehouse 2007-06-21 14:49:36 UTC
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.
Comment 3 David Teigland 2007-06-21 15:56:48 UTC
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.
Comment 4 Steve Whitehouse 2007-06-21 16:39:19 UTC
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.
Comment 5 David Teigland 2007-06-21 16:54:06 UTC
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?
Comment 6 Steve Whitehouse 2008-09-19 10:43:07 UTC
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.
Comment 7 Steve Whitehouse 2008-10-10 10:56:13 UTC
Patches posted to cluster-devel