[dm-devel] [PATCH 1/3] Send KOBJ_ADD event after dm resume ioctl.

[Alasdair G Kergon]

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