On Wed, Jan 10, 2018 at 04:35:56PM +0100, Zdenek Kabelac wrote: > > > Also ATM 'lvmetad' can't be used even with lvmlockd - simply > > > because we are not (yet) capable to handle 'udev' around the cluster > > > (and it's not clear we ever will). > > > > This sentence surprises me much. According to manpage of lvmlockd, it It surprises me too, since I developed lvmlockd and lvmetad features precisely to make it work. > > seems clear that lvmlockd can work with lvmetad now. > > IIRC, it's not the first time you mentioned about "cluster udev". It > > gives me a impression that the currect udev system is not > > 100% reliable for shared disks in cluster, no matter if we use lvmetad > > or not, right? If so, could you please give an example > > scenario where lvmetad may not work well with lvmlockd? > > The world of udevd/systemd is complicated monster - which has no notation for > handling bad/duplicate/.... devices and so on. > > Current design of lvmetad is not sufficient to live in ocean of bugs in this > category - so as said - ATM it's highly recommend to keep lvmetad off in > clusters. There are indeed plenty of problems with lvmetad, which is why I've been trying to get us to get rid of lvmetad, and improved disk scanning to be so much more efficient: https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-new-scan-32 However, you have not pointed out any specific problems unique to lvmlockd with lvmetad. _______________________________________________ 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/
