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

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

> opposite to the original clvm "single system image" design in which
> everything that happens is in theory meant to be happening everywhere.

Got it. Thanks again.


  reply	other threads:[~2018-01-10  7:11 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 [this message]
2018-01-10  9:36     ` Zdenek Kabelac
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).