[dm-crypt] renaming of device

Sven Eschenberg sven at whgl.uni-frankfurt.de
Mon Jan 18 15:58:20 CET 2010


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 at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>




More information about the dm-crypt mailing list