archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: LVM general discussion and development <>,
	Eric Ren <>
Subject: Re: [linux-lvm] The benefits of lvmlockd over clvmd?
Date: Wed, 10 Jan 2018 10:36:53 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Dne 10.1.2018 v 08:11 Eric Ren napsal(a):
> Hi David,
> Thanks for your explanations!
> On 01/10/2018 12:06 AM, David Teigland wrote:
>> On Tue, Jan 09, 2018 at 11:15:24AM +0800, Eric Ren wrote:
>>> Hi David,
>>> Regarding the question of the subject, I can think of three main benefits of
>>> lvmlockd over clvmd:
>>> - lvmlockd supports two cluster locking plugins: dlm and sanlock. sanlock
>>> plugin can supports up to ~2000 nodes
>>> that benefits LVM usage in big virtulizaton/storage cluster,
>> True, although it's never been tried anywhere near that many.  The main
>> point hiding behind the big number is that hosts are pretty much unaware
>> of each other, so adding more doesn't have any affect, and when something
>> happens to one, others are unaffected because they are unaware.
> The comments above is only talking about lvmlockd with sanlock, and it's
> because the different protocols/algorithms used by them: sanlock with Paxos,
> dlm with corosync, right?
>>> while dlm plugin fits HA clsuter.
>>> - lvmlockd has better design than clvmd. clvmd is command-line level based
>>> locking system, which means the
>>>   whole LVM software will get hang if any LVM command gets dead-locking
>>> issue. However, lvmlockd is *resources* based
>>> cluster locking. The resources to protect is VG and LV so that the deadlock
>>> issue will be isolated inside the resource and
>>> operations on other VG/LV can still proceed.
> Is this point roughly true?
>>> - lvmlockd can work with lvmetad.
>>> But, I may be wrong in some points. Could you please help correct me and
>>> complete the benefit list?
>> To me the biggest benefit is the design and internal implementation, which
>> I admit don't make for great marketing.  The design in general follows the
>> idea described above, in which hosts fundamentally operate unaware of
> Sorry, "the idea described above" by me?
>> others and one host never has any effect on another.  That's diametrically
> For example, with clvmd the command "lvchange -ay VG/LV" will try to activate 
> the LV
> on every hosts, but with lvmlockd, we need to perform "lvchange -asy" on each 
> host :)

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.

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.

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).

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.



  reply	other threads:[~2018-01-10  9:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09  3:15 [linux-lvm] The benefits of lvmlockd over clvmd? Eric Ren
2018-01-09 16:06 ` David Teigland
2018-01-10  7:11   ` Eric Ren
2018-01-10  9:36     ` Zdenek Kabelac [this message]
2018-01-10 14:42       ` Eric Ren
2018-01-10 15:35         ` Zdenek Kabelac
2018-01-10 17:25           ` David Teigland
2018-01-10 16:45     ` David Teigland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).