On Fri, Mar 19, 2010 at 10:59:12AM -0400, David Zeuthen wrote:It is a problem if both:
> 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.
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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
