<br><br><div class="gmail_quote">On Mon, May 14, 2012 at 9:43 AM, Zdenek Kabelac <span dir="ltr"><<a href="mailto:zkabelac@redhat.com" target="_blank">zkabelac@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Dne 12.5.2012 16:59, Nicholas Nevin napsal(a):<br>
<div><div class="h5">> Anyone have any thoughts on this?<br>
><br>
> Thanks, Nick.<br>
><br>
> On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <<a href="mailto:njnevin@gmail.com">njnevin@gmail.com</a>> wrote:<br>
><br>
>> In nightly testing of our product the tests do a fair bit of<br>
>> creating/destroying of device mapper devices and we have been seeing<br>
>> infrequent cases where the device is created OK but the corresponding<br>
>> /dev/mapper/<dm_name> symlink does not exist.<br>
>><br>
>> Here is an example of the dmsetup command used to create the devices.<br>
>><br>
>> # dmsetup create tap0 --table '0 47247164 linear /dev/xen/blktap-2/tapdev0<br>
>> 1'<br>
>><br>
>> I managed to reproduce this problem with udev logging enabled and 'udevadm<br>
>> monitor' running and from the logs the cause appears to be that the udev<br>
>> add action (from the device create) and the udev change action (from when<br>
>> the device is resumed after loading the table) are running<br>
>> concurrently. The processing of the rules for the change action creates the<br>
>> /dev/mapper/tap0 symlink but then the processing of the add action deletes<br>
>> the symlink because /dev/mapper/tap0 is not in the add action DEVLINKS.<br>
>><br>
>> The question I have is should dmsetup be ensuring that the add action<br>
>> completes before the change action is handled or is this behaviour expected?<br>
>><br>
>> That /dev/mapper/tap0 is not in the DEVLINKS for the add action is AFAICT<br>
>> because of a race between the creation of the sysfs entries for the device<br>
>> and the processing of the add action in udevd. This can be fixed by<br>
>> sprinkling in some WAIT_FOR conditions in the dm udev rules. Our system is<br>
>> based on Ubuntu 12.04.<br>
>><br>
>> I have attached the udevadm monitor output and the relevant piece of<br>
>> syslog for a test case where the /dev/mapper/tap0 symlink wasn't present<br>
>> when dmsetup returned.<br>
>><br>
>> I hope this is the right place to ask this. If not please point me in the<br>
>> right direction.<br>
<br>
</div></div>You have not specified version of lvm2 tools in use.<br></blockquote><div><br></div><div>Ah yes, here we go.</div><div><br></div><div>root@nick-lt:~# lvm version</div><div>  LVM version:     2.02.66(2) (2010-05-20)</div>

<div>  Library version: 1.02.48 (2010-05-20)</div><div>  Driver version:  4.22.0</div><div>root@nick-lt:~# dmsetup version</div><div>Library version:   1.02.48 (2010-05-20)</div><div>Driver version:    4.22.0</div><div>root@nick-lt:~# </div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But on udev system there are 2 options when nodes/links are created.<br>
<br>
By default it's on RESUME - since this is the moment table is defined,<br>
and proper messages are passed across udev system.<br>
<br>
For backward compatibility (and for non-udev systems) there is<br>
dmsetup create --addnodeoncreate  - which basically creates links on 'create'<br>
phase - but with old 'badness' behind - since normally no one should create<br>
nodes in /dev  - it's the  udev 'kingdom' which should not be externally<br>
modified (udev might not know about such entries).<br>
<br>
So the proper moment to work with created devices is after they have been<br>
resumed - everything else will be ugly udev hack with unpredictable results. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Zdenek<br></font></span></blockquote><div><br></div><div>Makes sense thanks. The problem seems to be though that the handling of the</div><div>add (on create) and change (on resume) actions coming from the kernel to udevd</div>

<div>are not handled sequentially by udevd which can cause problems such I described.</div><div>It seems to me that dmsetup should be ensuring that the add action upon create</div><div>has been fully handled before doing the resume which generates the change action.</div>

<div>I'm no expert though so I could well have things wrong here.</div><div><br></div><div>-nick</div><div><br></div></div>