<div>Hey,</div><div><br></div>On Fri, Mar 19, 2010 at 10:34 AM, Alasdair G Kergon <span dir="ltr"><<a href="mailto:agk@redhat.com">agk@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Mar 19, 2010 at 09:58:00AM -0400, David Zeuthen wrote:<br>
> I think the problem is the that fact that 3rd party user space<br>
> opens the device before it is ready (e.g. just after ADD but before<br>
> the first CHANGE) makes things fall over.<br>
> This short-coming is what needs to get fixed, I think - it's very<br>
> fragile this way and since any random user / package can add<br>
> rules to open the device on add events, said user / package can<br>
> make device-mapper fail. Which doesn't exactly strike me<br>
> as robust behavior.<br>
<br>
</div>And we suggested two potential solutions:<br>
<br>
  1 - change the kernel so the ADD event doesn't arrive until the device is<br>
ready for use.     [plus equivalent change for REMOVE]<br>
<br>
      Advantage: the dm device handling looks more like a real disk so we have<br>
less 'special case' code.  /dev then only indexes "dm devices ready to be used"<br>
rather than "dm devices registered in the kernel"<br>
<br>
      Disadvantage: breaks the currently-simple kobject/sysfs/dev linkage (as<br>
per Kay's earlier mail) </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
  2 - several changes to the way udev rules are handled so we can choose to<br>
ignore events and make no changes to /dev, so we can override rules other<br>
packages insert without requiring dm-specific checks adding to them all, and<br>
probably some of the other things we've discussed on these various threads.<br></blockquote><div><br></div><div>I don't think it's realistic to assume that user space will read and honor</div><div>something like a DM_UDEV_DISABLE_DM_RULES_FLAG property - while</div>
<div>we can make the udev package and other "core" OS packages do this, rules</div><div>from users, sites and random 3rd party packages will open() the device</div><div>on "add" (and, if properly written, also on "change").</div>
<div><br></div><div>It's much better to make that operation somehow gracefully fail in the</div><div>window where the device isn't configured. My understanding is that</div><div>we are not doing this today - for example, suppose I have this udev</div>
<div>rule</div><div><br></div><div>  SUBSYSTEM=="block", ACTION=="add|change", \</div><div>  IMPORT{program}="foo-check-for-some-signature $tempnode"</div><div><br></div><div>where foo-check-for-some-signature is some program to check for</div>
<div>a fs signature (say, for a properietary fs on a portable music</div><div>player device) and, if, so, set the FOO_* properties with specifics</div><div>about the device (these will be used in the UI to control/manage</div>
<div>the portable music player).</div><div><br></div><div>Things like this should work for any block device, no matter what</div><div>state it's in. Sure, for device-mapper block devices open() or</div><div>read() on the device may fail in the window between "add" and</div>
<div>"change" but that's fine.</div><div><br></div><div>What can never happen though, is that this configuration of the</div><div>device-mapper device somehow randomly fails because the</div><div>program foo-check-for-some-signature tries to open every block</div>
<div>device.</div><div><br></div><div><div>(Sure, user space can be _clever_ and save the fork+exec+open</div><div>by checking DM_UDEV_DISABLE_DM_RULES_FLAG from an</div><div>udev rule - but that's optimization, not something required for</div>
<div>correctness.)</div><div><br></div><div>I haven't checked if this problem still exists with device-mapper</div><div>but I know, in the past, that it has - and IIRC it was the reason</div><div>that you introduced DM_UDEV_DISABLE_DM_RULES_FLAG</div>
<div>after the udev ignore_device directive was removed.</div><div><br></div></div><div>I'd like to reiterate that it's actually not a problem that the sequence is</div><div><br></div><div> - "add" uevent</div>
<div> - device is not usable, access to the device fails gracefully</div><div> - "change" uevent</div><div> - device usable, blkid on the device etc. works</div><div><br></div><div>the point really is that you have to accept that there will exist</div>
<div>user space programs that does things on the device between</div><div>"add" and the initial "change" uevent.</div><div><br></div><div>The other problem, the assumption that "change" uevents only</div>
<div>originates from libdevmapper, is separate from this problem.</div><div><br></div><div>     David</div><div><br></div></div>