On Wed, Apr 29, 2009 at 03:16:23AM +0200, Kay Sievers wrote: > including all the userspace rename processing, means "move" uevents. So the concept for this already exists as "move". Good. > Also DM allows pretty stupid free-text device names, and names We took the view there was no need for any restrictions beyond '/' in the kernel and it was a matter for userspace to choose the namespace. LVM on the other hand, does limit the alphabet pretty severely. The workaround here would just be to map any characters outside the range udev permits into something else. > > E.g. Anything in userspace that opens /dev/something has to check that > > what it actually opened still has the same device number, if it cares > > about avoiding races. > No, we don't go and change device node names for the same device > number. You could do that with updated symlinks but not with the > primary nodes. I'm merely pointing out that we don't pass direct references to objects between userspace and kernel, but references stored in a filesystem, and between passing a /dev/something reference into the kernel and the kernel resolving it into its device number and the corresponding object, the /dev filesystem could have changed so that it now points to a different block device: and we make it the responsibility of userspace code to check that this race did not occur. > > 2) Change dm to insert dm-<name> into this field instead of dm-X > That will only work reliably if you can not change the name on the > fly. Otherwise it will get complicated to keep track of the devices. > Possible, but a real mess to get right. I think renaming is an important facility for users and we should delve further into the implications of handling that. > device names. If you allow that, we will need to limit it to plain > [a-zAZ-:.]. Plus numbers I presume? LVM accepts [a-zA-Z0-9+_.-] What about + and _ ? Would they also need to be escaped? > > And eventually perhaps: > > 7) Phase out /dev/mapper (in a suitably-compatible way as usual so we don't > > break anything) > Just keep it, what's wrong with it? If we had /dev/map-vg1-lvol1 directly it would be pointless duplication. Remember, when dm was written in the days before udev we had only /dev/mapper which we managed directly ourselves (or through devfs). I only became aware of /dev/dm-X when I started getting bug reports from users inadvertently using it for things they shouldn't. The root of all these problems has been dm and udev each having a different emphasis on their device transactions. (LVM/dm was designed around independent atomic transactions, which is what Peter has only now managed to retrofit into the udev framework.) > and proper hooks to plug into the processing. The last thing we need > here is some new special cases for DM, which do not fit into what all > others are doing. dm is already different because the whole philosophy is built around facilitating arbitrary device reconfigurations. The fewer spurious things like /dev/dm-X we offer to users and developers to hang themselves with, the better. This is why I get so cross when I receive bug reports of systems not booting because some tool didn't understand that and hard-coded a dynamic minor number into their initrd or fstab, which /dev/dm-X has been encouraging them to do. Renaming without rebooting, unfortunately, is something our users do seem to want to be able to do and we need to find ways of making it easier for them. In LVM terms, it's clustered LVM that makes this particularly tricky for us, and my latest proposal is to store both the old name and the new name in the LVM metadata and keep checking for both names with the tools presenting the new name until such time as it's safe to make the change (e.g. after the next reboot if it's a root filesystem) and forget about the old name completely. (Currently LVM only supports renaming in-use LVs within VGs, not renaming VGs while they contain in-use LVs.) Alasdair -- agk@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
