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
