All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: lvm-devel@redhat.com
Subject: lvmlockd: adopt locks always failed
Date: Tue, 8 Aug 2017 09:28:15 -0500	[thread overview]
Message-ID: <20170808142815.GA29769@redhat.com> (raw)
In-Reply-To: <59570f35-a284-dca3-983b-22bf3addf4f7@suse.com>

On Tue, Aug 08, 2017 at 10:03:58AM +0800, Eric Ren wrote:
> I add a resource agent for lvmlockd. It would be great if you can give some
> review and comments there ;-P  The PR is here:
> 
> https://github.com/ClusterLabs/resource-agents/pull/1013

Hi, thanks for working on that, resource agents have always seemed mostly
redundant to me, so I'm not one to give the best feedback.

You could simplify things by just starting lvmlockd from systemd during
system startup using
https://sourceware.org/git/?p=lvm2.git;a=blob_plain;f=scripts/lvm2_lvmlockd_systemd_red_hat.service.in;hb=HEAD

since there's no clustering dependency on doing that, i.e. no problem
starting the daemon before clustering components are started.  It doesn't
actually do anything until you start shared VGs.

I think we could make lock-adoption the default during startup.  I may
change the default in lvmlockd itself.  You always want to adopt locks if
they exist; things aren't going to work if you restart lvmlockd without
adopting locks when previous orphaned locks exist.  However, I'm not sure
that resource agents will be sophisticated enough to restart lvmlockd and
adopt locks after a previous instance failed; they've always seemed eager
to just reset the node.

Once the clustering system is running (in particular the dlm), you can
then start and use shared VGs.  You could use or copy this unit file for
that:

https://sourceware.org/git/?p=lvm2.git;a=blob_plain;f=scripts/lvm2_lvmlocking_systemd_red_hat.service.in;hb=HEAD

For activation, you need to use vgchange -aay to specify auto-activation.
You're also including 's' to activate LVs with a shared lock, but it's
only safe to do that if you have a cluster file system on the LV.  If you
don't have a way to know that, I've thought in the past that we could add
a new lvm.conf list, similar to auto_activation_volume_list, that
specifies which LVs should be activated with shared locks.  For
deactivation, use -an, (the 'l' was a clvm-ism, and is meaningless with
lvmlockd.)

Dave



  reply	other threads:[~2017-08-08 14:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  7:23 lvmlockd: adopt locks always failed Eric Ren
2017-08-07 15:47 ` David Teigland
2017-08-08  2:03   ` Eric Ren
2017-08-08 14:28     ` David Teigland [this message]
2017-08-09 10:11       ` Eric Ren

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=20170808142815.GA29769@redhat.com \
    --to=teigland@redhat.com \
    --cc=lvm-devel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.