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

[David Zeuthen]

On Fri, Mar 19, 2010 at 11:24 AM, Alasdair G Kergon <agk at redhat.com> wrote:

> On Fri, Mar 19, 2010 at 10:59:12AM -0400, David Zeuthen wrote:
> > I'd like to reiterate that it's actually not a problem that the sequence
> is
> >  - "add" uevent
> >  - device is not usable, access to the device fails gracefully
> >  - "change" uevent
> >  - device usable, blkid on the device etc. works
> > the point really is that you have to accept that there will exist
> > user space programs that does things on the device between
> > "add" and the initial "change" uevent.
>
> It is a problem if both:
>    1) something attempts to open the devices in that window
> AND 2) we have no mechanism to wait for it to finish
>
> Also note that if it is permitted to run 'udevadm trigger' at
> any time that also causes a synchonisation problem here: our
> application code doesn't even know there is something conflicting
> that it needs to wait for.  [Even though we want to ignore ADD,
> we may still need to synchronise against it.]
>
> So again, the 'don't issue ADD until device is usable' offers a simple
> way of avoiding this class of problems.


But as Kay said it's a horrible horrible hack.

If you wanted to solve the problem kernel-side I'd expect you to
create a new subsytem for device-mapper (let's call it 'kdm') that
libdevmapper would talk to. Then you'd only present block device
objects exactly when the device-mapper side has been configured.

Then the flow of events could be something like this

 - add device kdm-0  (subsys 'kdm')
 - libdevmapper configures kdm-0
 - add device dm-0 (subsys 'block')

but I don't know if this is better.


> The 'private device
> attribute' we suggested offers another - all would be expected
> to respect a 'private' sysfs attribute.
>

Sorry, but this is an even worse hack. Mandating that all of user
space (that is: past, present and future) needs to read some
random 'private' attribute in sysfs because of weird life-cycle
issues in the device-mapper implementation... that's not really
workable.

Anyway, I really don't think you can expect user space to behave
sanely so it's not really worth trying.

(I don't think you ever could expect user space to behave sanely,
but I'll note that it's an even bigger problem now that we have
powerful frameworks (such as udev) allowing people to run code
at device discovery time.... I mean, device-mapper have probably
been suffering from these issues from day 1 - it just wasn't visible
earlier on because we didn't have uevents...)

Thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20100319/9081b0c8/attachment.htm>