On 01/24/2014 04:17 PM, Zdenek Kabelac wrote: > Dne 24.1.2014 15:50, Marius Vollmer napsal(a): >> Peter Rajnoha <prajnoha@redhat.com> writes: >> >>> Thanks! Well, sorry for that, I've finally noticed the thing, >>> that was another bug, unfortunately. Should be solved now with >>> this git head in lvm2 upstream: >>> 89d77326170d020ebba6ae1c717c08ac4b07996a >>> (git.fedorahosted.org/git/lvm2.git) >>> >>> Thing is that the pool volume *should always* be marked >>> as private which also means DM_UDEV_DISABLE_OTHER_RULES_FLAG >>> is set. >> >> Nice, thanks! >> >> With this fixed, I have to ask again: Is _every_ situation where a block >> device goes from public to private with a "change" event a bug? >> >> I would say "yes", simply because I can't think of a situation where >> LVM2 doesn't know from the start whether the device is creates is gonna >> be public or private. >> >> If so, we just keep UDisks2 as it is, I'd say, and I file bugs when I >> find another public->private transition. > > > This is probably worth to put here this comment: > > When lvm2 creates a complex device - it starts to build it from pieces. > However each individual piece is initially created as a visible plain LV. > > The reason behind this is - whenever lvm2 fails to finish the command > (or someone just press Power-Off button) - it should leave metadata in > the state, you can recover from with normal lvm2 command. > > This means - even if the lvm2 fails to build complex targets - it should > never leave metadata filled with 'private' LVs, which user cannot > delete with lvremove command. Of course this is currently just a > 'target' we try to reach and you are encourage to report bugs if you > notice ordering problems here (i.e. raids are not compatible with this > style). > > So while TEMPORARY flag fixes the 'OK-path' here - it actually may > introduce a problem of having a device with unknown content for udev in > the case of lvm2 command problem - but the assumption here is - the > system has far more serious troubles in such failures than you should > care about udev-db correctness... > > And there is more scary part behind this - the current NOSCAN and > TEMPORARY flags do work only non-clustered case. ...yes, using udev in cluster is a bit of scary thing to do, I have to admit :) -- Peter _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
