On Tue, Aug 26, 2008 at 10:47:37PM +0200, Karel Zak wrote: > There is worse scenario (thanks to Milan Broz from DM camp): > > dmsetup create x --table "0 100 linear /dev/sdb 0" > dmsetup create y --table "0 100 linear /dev/mapper/x 0" > dmsetup create z --table "0 100 linear /dev/mapper/y 0" > > # dmsetup ls --tree > z (254:3) > `-y (254:2) > `-x (254:1) > `- (8:16) > > it means all these devices are exactly same, but > > mount LABEL=foo > > has to mount /dev/mapper/z (from top of the tree). The sdb, x and > y should be invisible for the mount(8). Sure, but consider what happens when you create a snapshot (either read-only or read-write) of an existing filesystem? In that case, both the parent and the child filesystem is mountable, and if the child filesystem is transient, the praent one may not want to be transient. In fact, suppose the scenario is a virtualization scenario, where you create the parent, create child snapshots, then use "tune2fs -U random -L virt1 /dev/mapper/snap1" ; "tune2fs -U random -L virt2 /dev/mapper/snap2" and so on, so each of the child snapshots have their own independent identity separate from the parent, it may very *well* be the case that the parent device should be visible to mount. I don't think we can make the general argument that the leaf device is always mountable, and anything above it is *never* mountable. Maybe that's the default, but it's certainly not always true. I'm beginning the right answer is we need some assist from the device mapper infrastructure, where when we create the device mapper device, we specify whether or not it is mountable, and this information is made available somehow, either by trying to sneaking it into /proc/partitions (which will be tricky without breaking legacy programs), or by making it visible in /sys. > I think we can ignore this minor problem for now. I'll try to found a > better solution for dependencies resolution without libdevmapper. My > wish is to avoid libdevmapper in libfsprobe. Speaking of which, what is your plan for caching versus non-caching in libfsprobe? It seems to me that if you are going to be caching, you'll just be re-inventing blkid. If you don't cache, you'll either (a) have to iterate over all possible devices, which is what we did before blkid (it was Ric Wheeler pointed out to me this problem and I wrote blkid in response to his request, because it becomes a problem if you have hundred of LUN's getting exported by a large EMC storage array :-), or (b) do what vol_id does, which is depend on /dev/disk/by-label and /dev/disk/by-uuid, which has the charming Windows-like attribute of not getting updated until the next reboot --- which means after you create a new filesystem or swap device on an existing device, or change a label or UUID using tune2fs, vol_id never notices until the next reboot or until you physically unplug and reinsert the device. Or is the answer that you expect libfsprobe to only do filesystem type, uuid, and label detection, and not solve the "find a device given a uuid/label" problem? > > This does work, because we do find the /dev/mapper name via a > > brute-force search of /dev looking for a matching devno when we call > > blkid_devno_to_devname(). What I *can* do is do a special search of > > /dev/mapper first, but instead of looking for /dev/mapper/<ptname>, to > > do a readdir search of /dev/mapper looking for the matching devno. > > Not elegant, but... good enough :-) > > It would be nice to have /sys/block/dm-N/name where you can translate > the internal dm-N name to the real device name. Alasdair? Milan? :-) Or maybe the right answer is /proc/partitions should only export devicemapper devices that are "supposed" to be visible to mount, and instead of exporting dm-0, dm-1...., we export the real name via /proc/partitions? Or do you not want to have the user-visible name get pushed into the kernel? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
