[linux-lvm] The benefits of lvmlockd over clvmd?

[Eric Ren]

Zdenek,

Thanks for helping make this more clear to me :)

>
> There are couple fuzzy sentences - so lets try to make them more clear.
>
> Default mode for 'clvmd' is to 'share' resource everywhere - which 
> clearly comes from original 'gfs' requirement and 'linear/striped' 
> volume that can be easily activated on many nodes.
>
> However over the time - different use-cases got more priority so 
> basically every new  dm target (except mirror) does NOT support shared 
> storage (maybe raid will one day...).   So targets like snapshot, 
> thin, cache, raid  do require 'so called' exclusive activation.

Good to know the history about clvmd :)

>
> So here comes the difference -  lvmlockd  in its default  goes with 
> 'exclusive/local' activation and shared (old clvmd default) needs to 
> be requested.
>
> Another difference is -   'clvmd' world is 'automating' activation 
> around the whole cluster (so from node A it's possible to activate 
> volume on node B without ANY other command then 'lvchange).
>
> With 'lvmlockd' mechanism - this was 'dropped' and it's users 
> responsibility to initiate i.e. ssh command with activation on another 
> node(s) and resolve error handling.
>
> There are various pros&cons over each solution - both needs setups and 
> while 'clvmd' world is  'set & done'  lvmlockd world scripting needs 
> to be born in some way.

True.

> 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 
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?

>
> On the positive side - we are working hard to enhance 'scanning' speed 
> - so in majority of use-cases there is no real performance gain with 
> lvmetad usage anyway.

Great! Thanks.

Regards,
Eric