Hi Milan, Thanks for yoru thorough reply, it helped correnting some misinterpreatations (namely udev/multipath uevents) and get a better overall picture. Regards -Sven On Mon, January 18, 2010 15:06, Milan Broz wrote: > On 01/16/2010 07:52 PM, Sven Eschenberg wrote: >> 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? > > Both. Block device uevents + required udev rules (provided by lvm2 > device-mapper subpackage). > > (Note the dm-uevents kernel configure option is only related to multipath > path > notification, basic uevents related to DM devices are sent always). > > Simplified, it works this way now: > > 1) some sybsystem (lvm2, cryptsetup, etc) configures DM-device in kernel > and waits for completion > > 2) DM (kernel module) send uevent when the device is > created/reconfigured/removed > > 3) (hotplug) udev device-mapper rule processes event and update /dev/ > layout (nodes, symlinks, etc.) > then sends notification to waiting libdevmapper call from step 1) > (this notification uses dmsetup triggered from udev rules and > system-wide semaphores > identified by cookie value) > > There is still fallback to direct node manipulation - so if it prints > something > like "Falling back to direct link creation." something is broken, but > libdevmapper > tries to fix it (I guess this fallback will be removed in future.) > > Proper device-mapper udev-enabled installation of this require > - recent kernel (>=2.6.31, it must support DM uevent cookie which > identifies device) > - recent device-mapper userspace (part of lvm2, now includes also dm udev > rules, > must be compiled with udev support) > > (Just one note - device-mapper block devices are special, udev rules must > react > to change/remove event and ignore "add" event. This is because add event > is sent > by block layer too early but device mapper must initialize mapping table > etc.) > > Also other packages, which scan block devices (device-kit-disks aka > udisks) > must be updated to not interfere with udev rules. > > Also there was add new read-only uevent in 2.6.32 which breaks old udev > rules > (this breaks cryptsetup operation also). So be sure you have new userspace > of everything related before using that udev machinery:-) > > >> 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. > > Not sure - it depends if your distributions have all bits mentioned above > ready, > and also this can be completely different problem. > > I know only that Fedora rawhide now is fully dm udev enabled, not sure > about other > distributions. > >> On the other hand, dm-uvenets are still marked experimental in current >> kernels. > > See above - this is not related, basic block device uevents are sent > always. > > 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
