On 2010-02-26, at 15:47, Karel Zak wrote:
On Fri, Feb 26, 2010 at 01:07:36PM -0700, Andreas Dilger wrote:
The only type that has "_volume_member" is VMFS. In ZFS terms, the
aggregate is called a "pool", and a component member is a "VDEV", and
I'd prefer to stick to that if possible, just like MD uses
"linux_raid_member" and LVM uses "LVM2_member" for their component
devices. It seems "zfs_pool_member" or simply "zfs_member" would
be OK?
OK, "zfs_member" sounds good.
OK.
The other question that has come up is whether the "UUID" for a
component device should be the UUID of the component device itself,
or
that of the volume? It seems to be for the component device, so is
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?
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.
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.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
