On Mon, May 14, 2012 at 9:43 AM, Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
Dne 12.5.2012 16:59, Nicholas Nevin napsal(a):
You have not specified version of lvm2 tools in use.> Anyone have any thoughts on this?
>
> Thanks, Nick.
>
> On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <njnevin@xxxxxxxxx> 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.
Ah yes, here we go.
root@nick-lt:~# lvm version
LVM version: 2.02.66(2) (2010-05-20)
Library version: 1.02.48 (2010-05-20)
Driver version: 4.22.0
root@nick-lt:~# dmsetup version
Library version: 1.02.48 (2010-05-20)
Driver version: 4.22.0
root@nick-lt:~#
But on udev system there are 2 options when nodes/links are created.
By default it's on RESUME - since this is the moment table is defined,
and proper messages are passed across udev system.
For backward compatibility (and for non-udev systems) there is
dmsetup create --addnodeoncreate - which basically creates links on 'create'
phase - but with old 'badness' behind - since normally no one should create
nodes in /dev - it's the udev 'kingdom' which should not be externally
modified (udev might not know about such entries).
So the proper moment to work with created devices is after they have been
resumed - everything else will be ugly udev hack with unpredictable results.
Zdenek
Makes sense thanks. The problem seems to be though that the handling of the
add (on create) and change (on resume) actions coming from the kernel to udevd
are not handled sequentially by udevd which can cause problems such I described.
It seems to me that dmsetup should be ensuring that the add action upon create
has been fully handled before doing the resume which generates the change action.
I'm no expert though so I could well have things wrong here.
-nick
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
