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

On Wed, Jan 10, 2018 at 03:11:24PM +0800, Eric Ren wrote:
> > 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?


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

It's vague enough to pass I suppose, but I don't think comparing them in
terms of locking is very helpful, because clvmd is not really a locking
system, it's a parallel execution system.  Keep in mind we're generalizing
and largely discussing opinion here, so there are bound to be some valid
disagreements about this.

Using lvmlockd, lvm just acquires and releases simple locks around making
changes.  There's no notion of "nodes", no concept of remote/local.
Either a command gets a lock or it doesn't, not much else can happen or go
wrong, it's pretty trivial.

clvmd is vastly different: "all nodes" and remote/local nodes is the
central controlling idea.  Locks are not the main thing, the main thing is
running all commands in parallel everywhere.  There are endless ways
things can go wrong when trying to run commands in parallel on all nodes.
What's more, there's no point to it, since nothing actually needs to run
in parallel everywhere.

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

No, the idea I described about sanlock not being affected by other nodes.


      parent reply	other threads:[~2018-01-10 16:45 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
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 [this message]

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