linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: Eric Ren <zren@suse.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] The benefits of lvmlockd over clvmd?
Date: Tue, 9 Jan 2018 10:06:22 -0600	[thread overview]
Message-ID: <20180109160622.GB24472@redhat.com> (raw)
In-Reply-To: <bc1ccc58-1771-183b-2d40-1d8b198fb8b5@suse.com>

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.

> 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.
> 
> - 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
others and one host never has any effect on another.  That's diametrically
opposite to the original clvm "single system image" design in which
everything that happens is in theory meant to be happening everywhere.

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

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20180109160622.GB24472@redhat.com \
    --to=teigland@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=zren@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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