FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 04-30-2012, 12:08 PM
Nicholas Nevin
 
Default /dev/mapper/ symlink not being created

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.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-12-2012, 02:59 PM
Nicholas Nevin
 
Default /dev/mapper/ symlink not being created

Anyone have any thoughts on this?
Thanks, Nick.
On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <njnevin@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.



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-14-2012, 01:43 PM
Zdenek Kabelac
 
Default /dev/mapper/ symlink not being created

Dne 12.5.2012 16:59, Nicholas Nevin napsal(a):
> Anyone have any thoughts on this?
>
> Thanks, Nick.
>
> On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <njnevin@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.

You have not specified version of lvm2 tools in use.

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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-15-2012, 01:55 PM
Nicholas Nevin
 
Default /dev/mapper/ symlink not being created

On Mon, May 14, 2012 at 9:43 AM, Zdenek Kabelac <zkabelac@redhat.com> wrote:


Dne 12.5.2012 16:59, Nicholas Nevin napsal(a):

> Anyone have any thoughts on this?

>

> Thanks, Nick.

>

> On Mon, Apr 30, 2012 at 8:08 AM, Nicholas Nevin <njnevin@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.



You have not specified version of lvm2 tools in use.

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.0root@nick-lt:~# dmsetup versionLibrary version: * 1.02.48 (2010-05-20)Driver version: * *4.22.0root@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 theadd (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 createhas 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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-15-2012, 02:07 PM
Alasdair G Kergon
 
Default /dev/mapper/ symlink not being created

dmsetup and udev have the functionality needed to do this in a race-free
manner, but it's necessarily complicated and takes a while to get your head
around it. You'll need to use the dmsetup commands/options for udev cookies
described in the man page.

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-15-2012, 02:32 PM
Nicholas Nevin
 
Default /dev/mapper/ symlink not being created

On Tue, May 15, 2012 at 10:07 AM, Alasdair G Kergon <agk@redhat.com> wrote:


dmsetup and udev have the functionality needed to do this in a race-free

manner, but it's necessarily complicated and takes a while to get your head

around it. *You'll need to use the dmsetup commands/options for udev cookies

described in the man page.



Alasdair



Thanks.*I'll take a look at doing this.
-nick

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 05:43 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org