On 03/25/2015 05:30 PM, Benjamin Marzinski wrote: > On Mon, Mar 16, 2015 at 01:36:30PM +0100, Hannes Reinecke wrote: >> device-mapper has a 'cookie', which is inserted with the ioctl >> for modifying device-mapper devices. >> It is used as a synchronization point between udev and any other >> applications to notify the latter when udev has finished >> processing the event. >> Originally multipath would only use a single cookie for every >> transaction, and wait for that cookie at the end of the program. >> Which works well if you only have one transaction, but for several >> (like calling 'multipath') it will actually overwrite the cookie >> and fail to wait for earlier events. > > That shouldn't be happening. Looking at the dm_task_set_cookie code > > if (*cookie) { > if (!_get_cookie_sem(*cookie, &semid)) > goto_bad; > } else if (!_udev_notify_sem_create(cookie, &semid)) > goto_bad; > > The first time we use that cookie, it should be zero, so a new semaphore > will be created, and the id will be returned to us. Subsequent calls to > dm_task_set_cookie with the same cookie (which is now non-zero) should > just be using the same semaphore, allowing you you wait just one time on > all the actions linked to that cookie. This should be more efficient > than having to wait on each action (since udev can complete them in the > background as we go on). > > If there really are cookies that are not waited for, you should be able > to see that by running > > # dmsetup udevcookies > > After running the multipath command. Cookies won't go away until > someone waits for them. If there are cookies listed there, then my guess > would be that something is resetting conf->cookie to 0 after our first > call to dm_task_set_cookie. If there aren't, then it would appear that > something else, instead of not waiting for the cookies, is causing > device mapper to fail back to manual device node creation. > > If you can verify that you are passing the cookie value that you get > back from the first call to dm_task_set_cookie() into sebsequent calls, > and you still are seeing non-watited for cookies with "dmsetup > udevcookies" then that sounds to me like a problem in device-mapper, and > we should check that out. > Hmm. It _might_ have been caused by multipathd not properly synchronized with udev (the original service files didn't have a dependency on udev), hence the call to dm_udev_set_sync_support() would cause device-mapper to switch off the udev fallback. Speaking of nasty side-effects ... Can't we have a proper warning in dm_udev_set_sync_support(), alerting us that the system will not behave as expected? But with that resolved it might be that indeed the patch is not required. I'll check. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel