We've been over all this ground before, but here it is again FWIW On Fri, Mar 19, 2010 at 11:16:15AM +0100, Kay Sievers wrote: > It will not wait, the tools will just fail to open the device, and > udev will only create the basic device node, but not possible > metadata-based symlinks or anything like that. That is expected > behavior, udev will handle just fine. The needed information will only > be readable with the next "change" event, and be fully updated with > every "change" event after that. But while userspace code responding to the uevents is fiddling with the new node deciding what to do, the userspace code (e.g. lvm2) that is creating the device tree is continuing to manipulate it as these are multi-step processes. If code triggered by the uevents runs alongside the lvm2 code, stuff fails. (E.g. lvm2 wants exclusive access which it can't get because something reacting to the uevent opened the device temporarily - even though we could have told it not to bother as it would find nothing of interest on it yet - a concept of 'ignored' or 'private' devices). So we require a synchronisation mechanism so that the lvm2 code can wait for *everything* triggered by the uevents to finish before proceeding. (Or alternatively a mechanism to flag that other code reacting to uevents should ignore these devices at this stage.) We attempted to add the synchronisation ourselves (95-dm-notify.rules) but I think you pointed out there are still things outside our control that can be triggered without a mechanism to wait for them to finish. Alasdair -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
