From: Zdenek Kabelac <zkabelac@redhat.com>
To: Vladislav Bogdanov <bubble@hoster-ok.com>
Cc: Andreas Pflug <pgadmin@pse-consulting.de>,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM snapshot with Clustered VG [SOLVED]
Date: Fri, 15 Mar 2013 10:37:00 +0100 [thread overview]
Message-ID: <5142EBBC.6030300@redhat.com> (raw)
In-Reply-To: <5142E9DD.30701@hoster-ok.com>
Dne 15.3.2013 10:29, Vladislav Bogdanov napsal(a):
> 15.03.2013 12:00, Zdenek Kabelac wrote:
>> Dne 14.3.2013 22:57, Andreas Pflug napsal(a):
>>> On 03/13/13 19:30, Vladislav Bogdanov wrote:
>>>>
>>>>> Is there a way to find out if a LV is locked exclusively? lvs
>>>>> displaying
>>>>> -e-- instead of -a-- would be nice. Seems not even lvdisplay knows
>>>>> about
>>>>> exclusive locking.
>>>> That would break other tools which rely on their output. F.e. cluster
>>>> resource agents of libvirt (yes, it runs lvm tools rather then using
>>>> API, which is not yet complete btw). As I also need to obtain this
>>>> information, I think about writing simple tool (f.e. clvm_tool) which
>>>> would display needed info.
>>>>
>>>> As a workaround you can run lvchange -aly without force parameter. If it
>>>> succeeds, the volume is locked in a shared mode, otherwise it is locked
>>>> exclusively.
>>>
>>> Hm, thats one ugly workaround...
>>> How about a clvmd option, something like -l to list all locks and exit.
>>>
>>
>>
>> I think - the extension to 'lvs' command could be relatively simple
>> (adding a new column)
>
> Yes, that's correct.
>
>>
>> You may query for exclusive/local activation on the node.
>> (So you cannot just tell on which other node is the device active,
>> but you could print about these states:
>>
>> active exclusive local
>> active exclusive
>> active local
>> active
>
> You also may poll all know nodes, but that is a hack too.
>
> That's why I prefer to have this as a separate tool (with dlm_tool-like
> params and output) which lists node IDs and lock mode. Unfortunately do
> not have power to write it now.
>
> Are core LVM devels interested in these two features: lock conversion
> and managing remote node locks? If yes, then I can (hopefully) prepare
> git patches next week.
I'm not quite sure what do you mean by 'managing remote node locks' ?
Current login behind lvm command is -
You could activate LVs with the above syntax [ael]
(there is a tag support - so you could exclusively activate LV on remote
node in via some configuration tags)
And you want to 'upgrade' remote locks to something else ?
What would be the use-case you could not resolve with current command line args?
Is that supported by dlm (since lvm locks are mapped to dlm)?
How would you resolve error path fallbacks ?
Also I believe the clvmd protocol is out of free bits for extension,
so how the protocol would look like ?
Zdenek
next prev parent reply other threads:[~2013-03-15 9:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 11:28 [linux-lvm] LVM snapshot with Clustered VG Andreas Pflug
2013-03-01 15:41 ` Vladislav Bogdanov
2013-03-06 7:40 ` Andreas Pflug
2013-03-06 7:58 ` Vladislav Bogdanov
2013-03-06 9:15 ` Andreas Pflug
2013-03-06 9:35 ` Vladislav Bogdanov
2013-03-06 9:59 ` Andreas Pflug
2013-03-06 11:20 ` Vladislav Bogdanov
2013-03-06 12:17 ` Andreas Pflug
2013-03-06 13:28 ` Vladislav Bogdanov
2013-03-12 6:52 ` Andreas Pflug
2013-03-13 15:14 ` [linux-lvm] LVM snapshot with Clustered VG [SOLVED] Andreas Pflug
2013-03-13 16:53 ` Vladislav Bogdanov
2013-03-13 17:37 ` Andreas Pflug
2013-03-13 18:30 ` Vladislav Bogdanov
2013-03-14 21:57 ` Andreas Pflug
2013-03-15 9:00 ` Zdenek Kabelac
2013-03-15 9:29 ` Vladislav Bogdanov
2013-03-15 9:37 ` Zdenek Kabelac [this message]
2013-03-15 12:53 ` Vladislav Bogdanov
2013-03-15 13:11 ` Vladislav Bogdanov
2013-03-15 13:32 ` Zdenek Kabelac
2013-03-15 14:51 ` Vladislav Bogdanov
2013-03-15 15:02 ` Zdenek Kabelac
2013-03-15 15:36 ` Vladislav Bogdanov
2013-03-15 15:55 ` Zdenek Kabelac
2013-03-15 17:16 ` Vladislav Bogdanov
-- strict thread matches above, loose matches on Subject: below --
2013-03-15 16:31 David Teigland
2013-03-15 17:46 ` Vladislav Bogdanov
2013-03-15 18:38 ` David Teigland
2013-03-16 11:00 ` Vladislav Bogdanov
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=5142EBBC.6030300@redhat.com \
--to=zkabelac@redhat.com \
--cc=bubble@hoster-ok.com \
--cc=linux-lvm@redhat.com \
--cc=pgadmin@pse-consulting.de \
/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).