On Fri, Feb 26, 2010 at 01:07:36PM -0700, Andreas Dilger wrote: > On 2010-02-26, at 06:52, Karel Zak wrote: >> On Thu, Feb 25, 2010 at 06:13:50PM -0700, Andreas Dilger wrote: >>> One question I had was regarding naming of the TYPE. Currently we >>> are >>> using "zfs" for this, but the current code is only really detecting >>> the >>> volume information and has noting to do with mountable filesystems. >> >> The TYPE is used by mount(8) or fsck(8) if the fstype is not >> explicitly defined by user. >> >> I don't know if anything depends on the TYPE, but I don't see >> /sbin/mount.zfs, so it seems that zfs-fuse guys use something other. > > To me it seems better that if we expect mount.zfs to mount a single > filesystem from within the pool, then the TYPE of the disk that blkid is > detecting today is that of the "volume", so the TYPE should probably not > be "zfs". After the ZFS pool is imported it may be that we would > identify datasets with type "zfs", but that is a long way away from where > it is today. It probably also makes sense to change this from > BLKID_USAGE_FILESYSTEM to BLKID_USAGE_RAID. Yes. >> See for example vmfs.c where we have "VMFS" (mountable FS) and also >> "VMFS_volume_member" (storage). The both TYPEs are completely >> independent and you can selectively probe for FS or for the special >> volume rather than probe always for both. I think this concept is >> better that add a new identifier (e.g. CONTAINER). >> >> Note, we have USAGE identifier to specify kind of the type, for >> example raid, filesystem, crypto, etc. This is necessary for >> udevd and some desktop tools. (try: blkid -p -o udev <device>). >> >>> Should we rename the TYPE to be "zfs_vdev" (ZFS equivalent to >>> "lvm2pv") >>> instead of the current "zfs"? It is probably more desirable to keep >> >> Yes, TYPE="zfs" (mountable FS) and TYPE="zfs_volume_member" makes >> sense. (The "_volume_member" is horribly long, but we use it for >> compatibility with udev world.) > > 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. > 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 Good question. 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> For more details see: http://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg01048.html > I'm updating the patch, and will resend based on feedback here. > >>> Have you considered adding CONTAINER or similar identification to the >>> blkid.tab file, so that it is possible to determine that the >>> filesystem >>> with LABEL="home" is on CONTAINER="39u4yr-f5WW-dtD7-jDfr- >>> usGd-pYWf-qy6xKE", which in turn is the UUID of an lvm2pv on /dev/ >>> sda2? >> >> I'd like to avoid this if possible. Hmm... I'm wrong here. (As Ricardo said, there is nothing like a virtual device with ZFS or btrfs. It means we can call blkid for component devices only.) You're right that for things like ZFS or btrfs it makes sense to have two UUIDs (device and FS) for each libblkid entry. > The reason I was thinking about this is if, for example, I want to mount > "LABEL=home", I can see from blkid.tab that this is in an device called > /dev/mapper/vgroot-lvhome, but if that volume is not currently set up, I > have no way to know where it is or how to configure it (other than > possibly very weak heuristics based on the device name). If, instead, it > has a CONTAINER which matches the UUID of /dev/sda2 that device can be > probed based on its TYPE. In SAN configurations where there are many Yes. I understand. > devices that _might_ be available to this node (e.g. high-availability > with multiple servers) configuring every device/volume that the node can > see is probably a bad idea (e.g. the LVM or MD RAID configuration may > have changed). > > Instead, doing the probing at startup (so the mappings are available), > but having the volumes configured on demand when some filesystem/device > within it is being mounted makes more sense. Storing this hierarchical > dependency in a central place (blkid.tab) makes sense. Yes, this is not first time when someone is asking for a central place where we can store configuration for all dependencies between block devices. Unfortunately, this is not so simple. > That way, > udev/blkid can be told "I want to mount LABEL=home", it resolves this is > in CONTAINER={UUID} (e.g. LV UUID), then blkid locates $CONTAINER, and if > it resolves to a device that is not yet active we can at least know that > it is TYPE=LVM2_member, ask lvm2 to probe and configure the device(s) on > which $CONTAINER resides, repeat as necessary for e.g. MD member > sub-devices. This is udev job. The udev should be able to detect a new device and call dmsetup, lvm, mdadm, etc. > To note, this discussion is not strictly related to the ZFS case, it's > just something that I thought about while looking at the code. You have good questions :-) 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
