Hello David,
Happy new year!
On 01/03/2018 01:10 AM, David Teigland wrote:
* resizing an LV that is active in the shared mode on multiple hosts
It seems a big limitation to use lvmlockd in cluster:
Only in the case where the LV is active on multiple hosts at once,
i.e. a cluster fs, which is
On 01/02/2018 10:43 AM, Alasdair G Kergon wrote:
The key concept to grasp is that LVM works with devices (i.e. major
number + minor number pairs) rather than filesystem paths and it makes a
single "use or ignore" decision for each device (not for each path).
That seems even more misleading tha
On 01/02/2018 10:17 AM, Marian Csontos wrote:
I do not think that log shows what is processed. LVM displays device
names according to different option - preferred_names it is.
I see. It seems to me that, for the purpose of troubleshooting filter
processing, the literal path that matches a fil
Also there is no special handling for |.*| - a match against it gets treated as
a positive deliberate match, just the same way as a match against |/dev/sda2|.
Alasdair
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listin
The key concept to grasp is that LVM works with devices (i.e. major
number + minor number pairs) rather than filesystem paths and it makes a
single "use or ignore" decision for each device (not for each path).
One device might be reachable through more than one filesystem path that
lvm has been co
On 01/02/2018 04:35 PM, Gordon Messmer wrote:
On 01/02/2018 03:03 AM, Marian Csontos wrote:
Filters accept any device if any of it's "names" (all symbolic links)
is matched by an a pattern ("a|.*/|" in your case) and matches no
previous r pattern
I don't follow you. The name being processed
> * resizing an LV that is active in the shared mode on multiple hosts
>
> It seems a big limitation to use lvmlockd in cluster:
Only in the case where the LV is active on multiple hosts at once,
i.e. a cluster fs, which is less common than a local fs.
In the general case, it's not safe to assum
On Thu, Dec 28, 2017 at 04:30:09PM +0800, Eric Ren wrote:
> Hi David,
>
> I's afraid the statement below in description section of lvmlockd manpage:
>
> "
> · prevent concurrent activation of logical volumes
> "
>
> is easy for normal user to mistake it as: wow, lvmlockd doesn't support
> active
On 01/02/2018 03:03 AM, Marian Csontos wrote:
Filters accept any device if any of it's "names" (all symbolic links)
is matched by an a pattern ("a|.*/|" in your case) and matches no
previous r pattern
I don't follow you. The name being processed in that log *does* match a
previous r pattern.
On 01/02/2018 07:47 AM, Gordon Messmer wrote:
I'd like to avoid scanning LVs, and I thought I'd set global_filter
appropriately. The following logs show global_filter set to reject
^/dev/VolGroup/vm_, but the system is scanning
/dev/VolGroup/vm_wiki_data. Any hints as to what I'm doing wrong?
Hi David,
I see the comments on res_process():
"""
/*
* Go through queued actions, and make lock/unlock calls on the resource
* based on the actions and the existing lock state.
*
* All lock operations sent to the lock manager are non-blocking.
* This is because sanlock does not support loc
11 matches
Mail list logo
