Hi Milan, Short question: When you say, libdevmapper supposely hands creation of inodes and links to udev, do you mean really udev, or just creating uevents, that can be handled by any hotplug processor? That reminds me, just yesterday on one of my boxes I started getting a message, that udev IIRC cannot create some inode, because it is already existant (I guess cryptsetup created it as usual), I guess it's another sign of those transisitions. On the other hand, dm-uvenets are still marked experimental in current kernels. Regards -Sven On Sat, January 16, 2010 09:39, Milan Broz wrote: > On 01/16/2010 03:46 AM, Arno Wagner wrote: >> It does. Each possible /dev/sd<x> has a defined, fixed >> major/minor, see Documentation/devices.txt in a Linux kernel >> source tree. > > so long thread:-) > > Well, the situation is more complicated. > > If cryptsetup uses only "real" block devices (like /dev/sdaX), > then fix to display proper device is is trivial. > (Parsing is in cryptsetup internal, not system libdevmapper currently.) > > But if you have stacked devices "virtual block devices" > (crypt over MD or over LVM) it can be different - you want to see > /dev/VG/LV as device, not /dev/dm-X. > > (btw dm-X names are not persistent and were intended to be kernel internal > only, unfortunately now are visible in userspace because of unified > udev event processing. And renaming these nodes to me more user-frientdly > in kernel is not easy because of various name length limits and different > approach for renaming of active DM devices) > > But the real problem now is that device-mapper library is just > in process of transition to udev (all nodes and symlinks will be created > by udev and not internally in libdevmapper). > And this changed (unified) some nodes to symlinks and vice versa. > > With various maintainer's udev rules in various ditributions it creates > nice > mix and Debian usually modifies even default rules for dm devices. > > (Actually if you have an udev rule, which creates another node and not > symlink in /dev/scsi/..., it is probably not correct, it should be > symlink.) > > Anyway, I'll plan to fix it somehow in next minor release of cryptsetup > (1.1.1 probably). > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
