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.
Regards
Zdenek
_______________________________________________
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/
