On Mon, Mar 01, 2010 at 04:40:43PM -0700, Andreas Dilger wrote:
>> Unfortunately, we don't have any rules for these things. See btrfs.c
>> (that's better example than vmfs.c ;-) where we have "UUID" for
>> filesystem and "UUID_SUB" (subvolume uuid) for the device.
>>
>> The udev is able to use these UUIDs to create a hierarchy of symlinks,
>> something like:
>>
>> /dev/btrfs/<UUID>/<UUID_SUB>
>
> This is itself a bit confusing, because AFAIK btrfs can have multiple
> "filesystems" within the same volume, so it would seem that "UUID" is
> for the whole volume?
Good point. Now, libblkid uses:
UUID = btrfs_super_block->fsid
UUID_SUB = btrfs_super_block->btrfs_dev_item->uuid
but I also see
btrfs_super_block->btrfs_dev_item->fsid
which is uuid of FS who owns this device. Maybe it would be better to
use the "fsid" from btrfs_dev_item as UUID. Not sure.
> It would be good if we can come to some consensus for this, since in the
> case of LVM2 it is using "UUID" for the disk UUID (seems this should be
> "UUID_SUB"), and the volume group UUID is not printed at all (seems this
> should be "UUID", maybe with LABEL={vgname}), and the LV UUID is
> completely ignored.
Well, the PV UUID is stored in PV label, the others information about
LG and LV are in the metadata area in text format. The metadata are
optional and versioned, etc. Currently, nobody asks for such
information and I very happy that we don't have to parse the metadata :-)
Don't forget that the libblkid library is used to identify block
device content. For additional information/operations we usually call
RAID or volume-manager specific tools by udevd.
The libblkid library probes for PV and nothing other, so I think that
using the "UUID" is good enough, because we don't have to
differentiate between more UUIDs here.
> I'm ready with a ZFS patch to use "UUID" for the volume, and "UUID_SUB"
> for the disks, once we agree that this is correct.
Yes, makes sense.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
