[dm-devel] /dev/mapper/<dm_name> symlink not being created

[Nicholas Nevin]

Anyone have any thoughts on this?

Thanks, Nick.

On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <njnevin at gmail.com> wrote:

> In nightly testing of our product the tests do a fair bit of
> creating/destroying of device mapper devices and we have been seeing
> infrequent cases where the device is created OK but the corresponding
> /dev/mapper/<dm_name> symlink does not exist.
>
> Here is an example of the dmsetup command used to create the devices.
>
> # dmsetup create tap0 --table '0 47247164 linear /dev/xen/blktap-2/tapdev0
> 1'
>
> I managed to reproduce this problem with udev logging enabled and 'udevadm
> monitor' running and from the logs the cause appears to be that the udev
> add action (from the device create) and the udev change action (from when
> the device is resumed after loading the table) are running
> concurrently. The processing of the rules for the change action creates the
> /dev/mapper/tap0 symlink but then the processing of the add action deletes
> the symlink because /dev/mapper/tap0 is not in the add action DEVLINKS.
>
> The question I have is should dmsetup be ensuring that the add action
> completes before the change action is handled or is this behaviour expected?
>
> That /dev/mapper/tap0 is not in the DEVLINKS for the add action is AFAICT
> because of a race between the creation of the sysfs entries for the device
> and the processing of the add action in udevd. This can be fixed by
> sprinkling in some WAIT_FOR conditions in the dm udev rules. Our system is
> based on Ubuntu 12.04.
>
> I have attached the udevadm monitor output and the relevant piece of
> syslog for a test case where the /dev/mapper/tap0 symlink wasn't present
> when dmsetup returned.
>
> I hope this is the right place to ask this. If not please point me in the
> right direction.
>
> Thanks, Nick.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20120512/cf15d361/attachment.htm>