On Wed, Apr 29, 2009 at 04:45, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > 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. Please stop dreaming. >> 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. And these days are over. /dev is not the thing anymore where everybody can mess around. > 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. Sounds good. >> > 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. Please! >> > 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? Sure. > LVM accepts [a-zA-Z0-9+_.-] > What about + and _ ? Would they also need to be escaped? "#+-.:=@_" and validated utf8 sequences are not 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. It's your call, I just try to ask you to fix the stuff first and _ship_ it, before it break it even further as it already is. Thanks! > 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. Sure, we are talking to you guys since years. What else should we do? Now you wake up after 5 years and think you want to change everything we do today? I'm confused. > 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. And again: BLOCK DEVICES HAVE THE KERNEL NAME AS THE DEVICE NODE NAME. > 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.) Sure rename them. But if you want the device node renamed, rename the kernel devices too. Thanks, Kay -- 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
