Karel Zak <kzak@xxxxxxxxxx> writes: >> # mount -oloop /tmp/volume /mnt/ >> # mount -oloop /tmp/volume /mnt/ >> # mount >> /tmp/volume on /mnt type ext2 (rw,loop=/dev/loop0) >> /tmp/volume on /mnt type ext2 (rw,loop=/dev/loop1) > > I know about this problem and it's "fixed" in Fedora util-linux > package (almost for two years)... Ah thanks, I did not realize this patch. > ... but I didn't port the patch to util-linux-ng, because I'm still > not sure that this is a good idea. > > Thanks for your note about offsets -- it's a good reason to drop the > stupid Fedora patch. > > Now other problem comes to mind -- hardlinks... Max's hint with > lo_node is good. Yes, the idea from Max seems to be much better. >> Any thoughts about this or something I have missed? > > Doesn't have kernel all information? Why this is not disabled by > kernel? Why this issues should be resolved by an userspace util when > kernel supports it? Is it real problem for all filesystems? Doesn't > exist same issue with multipath devices (SANs)? Good point. I am really not sure if setting up two loop devices with identical parameters should be forbidden by the kernel. There might be reasons these are valid use cases? Thats why I wanted to apply the check only for mount -oloop to avoid two identical mounts as given in the example above. The problem here is that the mount is a two step process: 1. Setting up loop device, 2. mount, but appears transparently as one step to the user. However, the behaviour is different for normal block devices and loop devices. I think from a users POV mount should behave consistently. > Maybe we can add a warning message to losetup only. The losetup > shouldn't be more "smart" than kernel or end-user -- I'd like to > follow kernel in this case. Yes, I agree. losetup as a low level tool shouldn't be smarter than the user and only be restricted by the kernel itself. I haven't been thinking about losetup itself, but the mount -oloop case. Matthias - To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
