Re: [linux-lvm] lvcreate hangs forever and udev work timeout

[Eric Ren]

Hi,

The reason is found out, as you've predicted.

> is it because of slow read operation (i.e. some raid arrays are known to
> wake-up slowly)

The udev worker is blocked until timeout before killed, cause the
"blkid" in /usr/lib/udev/rules.d/13-dm-disk.rules is too slow because
of high IO load on the thin pool.

After remove this rule:

IMPORT{builtin}="blkid"

for testing, the problem cannot be reproduced any more.

But, we tried to increate udevd timeout to 5 min, the problem still
happens; with 10 min timeout, can workaround this problem.

>From my understanding, the blkid will only read the fs superblock, why
it takes so long for a small IO to finish, even under high IO load?

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] [lvm-devel] lvcreate hangs forever and udev work timeout

[Eric Ren]

Hi,

> Hmm would it be possible that associated thin pool would be in some erroneous
> condition - i.e. out-of-space - or processing some resize ?

The testing model is:

create/mount/"do IO" (on) thin LV; and then umount/delete thin LV.

doing this work flow in parallel.

> This likely could result into some significant processing delay ?
>
> Since you are using very ancient lvm2  (2.02.130) we have heavily improved
> logic for such pools over the time...

Hah, I think I've mentioned this issue can be reproduced on centos 7.6
(2.02.180).

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvcreate hangs forever and udev work timeout

[Eric Ren]

Hi,

> Although the /dev/dm-26 is visible, but the device seems not ready in kernel.

Sorry, it's not:

[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup info /dev/dm-26
Device dm-26 not found
Command failed.

[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup info /dev/dm-25
Name:  vg0-21
State: ACTIVE
Read Ahead:256
Tables present:LIVE
Open count:0
Event number:  0
Major, minor:  252, 25
Number of targets: 1
UUID: LVM-PIFRRbKrhSqE5j6Q8jfk1qJJ1TNFPUI2SzDoe3z1azKH6HAOPsleizy3LozEMJus

[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup status | grep vg0-22
vg0-22: 0 20971520 thin 274432 20971519

[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup info vg0-22
Name:  vg0-22
State: ACTIVE
Read Ahead:256
Tables present:LIVE
Open count:0
Event number:  0
Major, minor:  252, 26
Number of targets: 1
UUID: LVM-PIFRRbKrhSqE5j6Q8jfk1qJJ1TNFPUI2YMnwPdLNF3JggAzXGwaFujcPePyOAeqd

Regard.

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvcreate hangs forever and udev work timeout

[Eric Ren]

Hi,

> Since the /dev/dm-x has been created, I don't understand what it waits
> udev to do?
> Just waits udev rules to create device symbol links?

Although the /dev/dm-26 is visible, but the device seems not ready in kernel.

[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup udevcookies
Cookie   Semid  Value  Last semop time   Last change time
0xd4d0b57225214464  2  Fri Apr 12 17:33:14 2019  Fri Apr
12 17:33:14 2019

[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup info /dev/dm-26
Device dm-26 not found
Command failed.

[root@iZuf6dbyd7ede51sykedamZ ~]# ls -l /dev/dm-26
brw-rw 1 root disk 252, 26 4月  12 17:33 /dev/dm-26

Regards.

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvcreate hangs forever and udev work timeout

[Eric Ren]

Hi!

> When udev kills its worker due to timeout - so udev rules was not finished
> within predefined timeout (which unfortunately changes according to mind
> change of udev developer - so it ranges from 90seconds to 300seconds depending
> on date of release) - you need to look out for reason why the timeout happens 
> -
>
> - is it because disk read was dead ?
>
> - is it because it's overloaded system ?
>
> - is it because of slow read operation (i.e. some raid arrays are known to
> wake-up slowly)
>
> - was udev rule accessing something it shouldn't even read ?

Thanks for these hints. Next time, I will collect the udev events
while trying to reproduce.

Again, I reproduced this on centos 7.6 with lvm2-1.02.180, full log
file will be attached.

>
> Once you know this - you can decide what's the best solution - you can
> extended default timeout to larger value  (i.e. 300 used to be usually good
> for this case)  you can fix/replace your failing drive.

When lvcreate hangs, the /dev/dm-26 has been visible, but the
/dev/vg0/22 symbol link is not ready.

Abstracted from the log, it waits for the udev cookie count to become zero:
"""
libdm-common.c:2433  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464) created
libdm-common.c:2453  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
incremented to 1
libdm-common.c:2325  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
incremented to 2
libdm-common.c:2575  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
assigned to RESUME task(5) with flags DISABLE_LIBRARY_FALLBACK
(0x20)
...
libdm-deptree.c:1302  lvcreate  Resuming vg0-22 (252:26).
...
libdm-common.c:2325  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
incremented to 3
libdm-common.c:2575  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
assigned to RESUME task(5) with flags DISABLE_LIBRARY_FALLBACK
(0x20)
...
activate/fs.c:491   lvcreate  Syncing device names
libdm-common.c:2360  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
decremented to 2
libdm-common.c:2646  lvcreate  Udev cookie 0xd4d0b57 (semid 225214464)
waiting for zero
"""

Since the /dev/dm-x has been created, I don't understand what it waits
udev to do?
Just waits udev rules to create device symbol links?


> lvm2 can be unblocked with 'dmsetup udevcomplete_all'  I guess until udev API
> will propagate its runtime timeout we can't do much more ATM...

Thanks! I remembered there is such a command, but cannot think it up

>
> You can enable full udev debugging to obtain the reasoning which rule was
> executed and got frozen.

OK.

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] lvcreate hangs forever and udev work timeout

[Eric Ren]

Hi,

As subject, it seems a interaction problem between lvm and systemd-udev:

```
#lvm version
  LVM version: 2.02.130(2)-RHEL7 (2015-10-14)
  Library version: 1.02.107-RHEL7 (2015-10-14)
  Driver version:  4.35.0
```

lvm call trace when hangs:
```

(gdb) bt
#0  0x7f7030b876a7 in semop () from /lib64/libc.so.6
#1  0x7f70312b708c in _udev_wait (cookie=223161260) at libdm-common.c:2522
#2  dm_udev_wait (cookie=223161260) at libdm-common.c:2540
#3  0x55e23866a60d in fs_unlock () at activate/fs.c:491
#4  0x55e238677855 in _file_lock_resource (cmd=,
resource=, flags=256, lv=) at
locking/file_locking.c:64
#5  0x55e23860a6c8 in _lock_vol (cmd=cmd@entry=0x55e239595000,
resource=, resource@entry=0x7ffe634b06b0 "#sync_names",
flags=flags@entry=256, lv_op=lv_op@entry=LV_NOOP,
lv=lv@entry=0x0) at locking/locking.c:275
#6  0x55e23860b013 in lock_vol (cmd=cmd@entry=0x55e239595000,
vol=, vol@entry=0x55e2386aae91 "#sync_names",
flags=flags@entry=256, lv=lv@entry=0x0) at locking/locking.c:355
#7  0x55e23860bcf0 in sync_dev_names
(cmd=cmd@entry=0x55e239595000) at locking/locking.c:536
#8  0x55e2385b4c4b in lvcreate (cmd=0x55e239595000,
argc=, argv=) at lvcreate.c:1534
#9  0x55e2385bd388 in lvm_run_command
(cmd=cmd@entry=0x55e239595000, argc=1, argc@entry=8,
argv=0x7ffe634b0df0, argv@entry=0x7ffe634b0db8) at lvmcmdline.c:1655
#10 0x55e2385bddf0 in lvm2_main (argc=8, argv=0x7ffe634b0db8) at
lvmcmdline.c:2121
```

systemd udev logs:
```
Apr 12 10:54:41 localhost.localdomain systemd-udevd[1363]: worker
[128147] /devices/virtual/block/dm-4 timeout; kill it
Apr 12 10:54:41 localhost.localdomain systemd-udevd[1363]: seq 2342985
'/devices/virtual/block/dm-4' killed
```

Is this a known issue? Please ask if any information needed :-)

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Aborting. LV mythinpool_tmeta is now incomplete

[Eric Ren]

Hi,

> So do you get  'partial' error on thin-pool activation on your physical 
> server ?

Yes, the VG of the thin pool only has one simple physical disk, at
beginning, I also suspected the disk may disconnect at that moment.
But, I start to think maybe it is caused by some reason hidden in the
interaction between lvm and dm driver in kernel.

It can not be reproduced easily, but happens randomly for several
times. The behavior model of lvm abstracted from the upper service is
like:
there are many (64) control flow in parallel, in each  one it loops to
randomly create/activate/delete thin LVs.

The error happened two place:
1. activate the thin LV:  _lv_activate -> _tree_action ->
dev_manager_activate ->  _add_new_lv_to_dtree -> add_areas_line  ->
striped_add_target_line on **metadata LV**,
I don't what .add_target_line() does for?

2. fail to suspend the origin LV when created.

I'm trying to reproduce it in a simple way, will report once succeed :-)

Thanks very much!
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Aborting. LV mythinpool_tmeta is now incomplete

[Eric Ren]

Hi Zdenek,

Thanks for your reply. The use case is for containerd snapshooter, yes, all
lvm setup is on host machine, creating thin LV for VM-based/KATA container
as rootfs.

For example:
https://github.com/containerd/containerd/pull/3136

and

https://github.com/containerd/containerd/pull/3022

So, we're evaluating such solution now~

Thanks,
Eric



On Thu, 11 Apr 2019 at 19:04, Zdenek Kabelac  wrote:

> Dne 11. 04. 19 v 2:27 Eric Ren napsal(a):
> > Hello list,
> >
> > Recently, we're exercising our container environment which uses lvm to
> manage
> > thin LVs, meanwhile we found a very strange error to activate the thin
> LV:
> >
>
>
> Hi
>
>
> The reason is very simple here - lvm2 does not work from containers.
> It's unsupported and if it partially works - it's a pure lucky case.
>
> ATM it's simply clear statement that lvm2 cannot be used from container
> simply
> because block layer is not namespaced.
>
> I'd give here long list of reason why it currently cannot work, but for
> now  -
> you should focus on making all 'device-block' operation on you host - and
> pass
> results to container.
>
> Regards
>
> Zdenek
>


-- 
- Eric Ren
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Aborting. LV mythinpool_tmeta is now incomplete

[Eric Ren]

Hi,


> Hi,

I could recommend to orient towards the solution where the 'host' system
> provides some service for your containers -  so container ask for action,
> service orchestrates the action on the system - and returns asked resource
> to
> the container.
>

Right, it's all k8s, containerd, OCI runtime are doing.


>
> IMHO I don't see any other usable solution ATM - although many container
> developers seems to endlessly try to run these system commands from a
> container...
>

Sorry, I don't make it clear. I mean we don't use lvm in container, we  use
thin pool on physical server, create thin LV, passthrough thin dm device
into virtual machine (KATA VM, not cgroup container) as VM's
rootfs.

Thanks,
Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Aborting. LV mythinpool_tmeta is now incomplete

[Eric Ren]

Hi,

Another error message is:

" Failed to suspend thin snapshot origin ..."

which is in _lv_create_an_lv():

```
7829 } else if (lv_is_thin_volume(lv)) {
7830 /* For snapshot, suspend active thin origin first */
7831 if (origin_lv && lv_is_active(origin_lv) &&
lv_is_thin_volume(origin_lv)) {
7832 if (!suspend_lv_origin(cmd, origin_lv)) {
7833 log_error("Failed to suspend thin
snapshot origin %s/%s.",
7834   origin_lv->vg->name,
origin_lv->name);
7835 goto revert_new_lv;
7836 }
7837 if (!resume_lv_origin(cmd, origin_lv)) { /*
deptree updates thin-pool */
7838 log_error("Failed to resume thin
snapshot origin %s/%s.",
7839   origin_lv->vg->name,
origin_lv->name);
7840 goto revert_new_lv;
7841 }
7842 /* At this point remove pool messages,
snapshot is active */
7843 if (!update_pool_lv(pool_lv, 0)) {
7844 stack;
7845 goto revert_new_lv;
7846 }
```

I don't understand why we need to suspend_lv_origin()
and resume_lv_origin() in line?

And, what reasons might cause this errors?

Regards,
Eric




On Thu, 11 Apr 2019 at 08:27, Eric Ren  wrote:

> Hello list,
>
> Recently, we're exercising our container environment which uses lvm to
> manage thin LVs, meanwhile we found a very strange error to activate the
> thin LV:
>
> “Aborting.  LV mythinpool_tmeta is now incomplete and '--activationmode
> partial' was not specified.\n: exit status 5: unknown"
>
> centos 7.6
> # lvm version
>   LVM version: 2.02.180(2)-RHEL7 (2018-07-20)
>   Library version: 1.02.149-RHEL7 (2018-07-20)
>   Driver version:  4.35.0
>
> It has appeared several times, but can not be reproduced easily by simple
> steps, and it only errors at that moment, after it happens everything seems
> OK but only that activation failed.
>
> Looking at the code a bit. At first, I suspect the PV may disappear for
> some reason, but the VG sits on only one PV, the setup is simple, the
> environment is only for testing purposes, it seems unlikely the PV has
> problem at that moment and I don't see any problem message with the disk.
>
> ```
>
> 2513 /* FIXME Avoid repeating identical stat in 
> dm_tree_node_add_target_area */
> 2514 for (s = start_area; s < areas; s++) {
> 2515 if ((seg_type(seg, s) == AREA_PV &&
> 2516  (!seg_pvseg(seg, s) || !seg_pv(seg, s) || 
> !seg_dev(seg, s) ||
> 2517!(name = dev_name(seg_dev(seg, s))) || !*name ||
> 2518stat(name, ) < 0 || !S_ISBLK(info.st_mode))) 
> ||
> 2519 (seg_type(seg, s) == AREA_LV && !seg_lv(seg, s))) {
> 2520 if (!seg->lv->vg->cmd->partial_activation) {
> 2521 if 
> (!seg->lv->vg->cmd->degraded_activation ||
> 2522 !lv_is_raid_type(seg->lv)) {
> 2523 log_error("Aborting.  LV %s is 
> now incomplete "
> 2524   "and '--activationmode 
> partial' was not specified.",
> 2525       
> display_lvname(seg->lv));
> 2526 return 0;
>
> ```
> So, does anyone see the same problem? Or any hints to hunt the root cause?
> Any suggestion would be welcome!
>
> Regards,
> Eric
>


-- 
- Eric Ren
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] Aborting. LV mythinpool_tmeta is now incomplete

[Eric Ren]

Hello list,

Recently, we're exercising our container environment which uses lvm to
manage thin LVs, meanwhile we found a very strange error to activate the
thin LV:

“Aborting.  LV mythinpool_tmeta is now incomplete and '--activationmode
partial' was not specified.\n: exit status 5: unknown"

centos 7.6
# lvm version
  LVM version: 2.02.180(2)-RHEL7 (2018-07-20)
  Library version: 1.02.149-RHEL7 (2018-07-20)
  Driver version:  4.35.0

It has appeared several times, but can not be reproduced easily by simple
steps, and it only errors at that moment, after it happens everything seems
OK but only that activation failed.

Looking at the code a bit. At first, I suspect the PV may disappear for
some reason, but the VG sits on only one PV, the setup is simple, the
environment is only for testing purposes, it seems unlikely the PV has
problem at that moment and I don't see any problem message with the disk.

```

2513 /* FIXME Avoid repeating identical stat in
dm_tree_node_add_target_area */
2514 for (s = start_area; s < areas; s++) {
2515 if ((seg_type(seg, s) == AREA_PV &&
2516  (!seg_pvseg(seg, s) || !seg_pv(seg, s) ||
!seg_dev(seg, s) ||
2517!(name = dev_name(seg_dev(seg, s))) || !*name ||
2518stat(name, ) < 0 || !S_ISBLK(info.st_mode))) ||
2519 (seg_type(seg, s) == AREA_LV && !seg_lv(seg, s))) {
2520 if (!seg->lv->vg->cmd->partial_activation) {
2521 if
(!seg->lv->vg->cmd->degraded_activation ||
2522 !lv_is_raid_type(seg->lv)) {
2523 log_error("Aborting.  LV
%s is now incomplete "
2524   "and
'--activationmode partial' was not specified.",
2525   display_lvname(seg->lv));
2526 return 0;

```
So, does anyone see the same problem? Or any hints to hunt the root cause?
Any suggestion would be welcome!

Regards,
Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] buffer overflow detected: lvcreate terminated

[Eric Ren]

Hi Marian,

I have a lvm failure below when creating a lot of thin snapshot LVs for
containers as rootfs.

```
*** buffer overflow detected ***: lvcreate terminated\n=== Backtrace:
=\n/lib64/libc.so.6(__fortify_*fail*
+0x37)[0x7f192c2389e7]\n/lib64/libc.so.6(+0x115b62)[0x7f192c236b62]\n/lib64/libc.so.6(+0x117947)[0x7f192c238947]\n/lib64/libdevmapper-event.so.1.02(+0x21db)[0x7f192cfd21db]\n/lib64/libdevmapper-event.so.1.02(daemon_talk+0xb5)[0x7f192cfd2a55]\n/lib64/libdevmapper-event.so.1.02(+0x331b)[0x7f192cfd331b]\n/lib64/libdevmapper-event.so.1.02(dm_event_get_registered_device+0x77)[0x7f192cfd3a47]\nlvcreate(monitor_dev_for_events+0x3cc)[0x556ec3b5d75c]\nlvcreate(monitor_dev_for_events+0x2ee)[0x556ec3b5d67e]\nlvcreate(lv_suspend_if_active+0x6cc)[0x556ec3b5f25c]\nlvcreate(+0x14196d)
```

My LVM version:
```
#lvm version
  LVM version: 2.02.180(2)-RHEL7 (2018-07-20)
  Library version: 1.02.149-RHEL7 (2018-07-20)
  Driver version:  4.35.0
```
I see you recently pushed this patch, looks like a fix for such problem:

```
commit fdb6ef8a85e9adc4805202b3200b17bd3b351982
Author: Marian Csontos 
Date:   Thu Jun 21 10:20:09 2018 +0200

libdm: fix buffer overflow

(cherry picked from commit 8a0af1bec882de66677e1a0cdceff841c39f92b0)
```

May I ask your help for some confirmation?

- how can we reproduce this problem?
- do you think this patch can fix my problem?

Thanks in advance!
Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Question about thin-pool/thin LV with stripes

[Eric Ren]

Hi Zdenek,

When 'stripe_size' is the 'right size' - striped device should appear
> faster,
> but telling you what's the best size is some sort of 'black magic'  :)
>
> Basically - strip size should match boundaries of thin-pool chunk sizes.
>
> i.e. for thin-pool with 128K chunksize -  and 2 disks -
> I'd assume best result you should get with 64K stripesize (so 2 disks will
> make it 128K stripe)  - but it depends on number of hw aspects.
>
> So you will need to benchmark it.
>

 Thanks a lot for your input! Very helpful points to take more
consideration~

Best regards,
Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Question about thin-pool/thin LV with stripes

[Eric Ren]

Hi,

With single command to create thin-pool, the metadata LV is not created
> with striped
> target. Is this designed on purpose, or just the command doesn't handle
> this case very
> well for now?
>
> My main concern here is, if the metadata LV use stripped target, can
> thin_check/thin_repair tools work fine?
>

In our use scenario, we want to use DM thinp for a lot of containers as
rootfs. The container use heavy on snapshots,
so above 4K thin/snapshots LVs may share the thin pool concurrently.

This may make the space fragmented. So, another concern is, will using
striped thinp make
fragmentation much more worse?

Thanks!
Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Question about thin-pool/thin LV with stripes

[Eric Ren]

Hi,

As you can see, only "mythinpool_tdata" LV has 2 stripes. Is that OK?
> If I want to benefit performance from stripes, will it works for me? Or,
> should I create dataLV, metadata LV, thinpool and thin LV using
> step-by-step way
> and specify "--stripes 2" in every steps?
>

With single command to create thin-pool, the metadata LV is not created
with striped
target. Is this designed on purpose, or just the command doesn't handle
this case very
well for now?

My main concern here is, if the metadata LV use stripped target, can
thin_check/thin_repair tools work fine?


>
> Besides, is there anything I should take care of to extend the
> VG/thin-pool with *striped thin-LV*
> when out of space?
>

In this case, I should always vgextend the VG with 2 PVs, because thin pool
will find the half-of-extending-size
of free space on 2 seperate PVs for striping. If just adding one PV, the
free space in VG cannot be used
to extend the 2-striped thin-pool.

Thanks,
Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] Question about thin-pool/thin LV with stripes

[Eric Ren]

Hello,

I created thin LVs with 2 stripes on two PVs as follows:

```
lvcreate --yes --zero=n --type=thin-pool --name=mythinpool
--extents=90%FREE --chunksize=512K --poolmetadatasize=1G --stripes=2
--stripesize=4K vg0
...
# lvs -o+stripes -a
  LV VG  Attr   LSizePool   Origin Data%
Meta%  Move Log Cpy%Sync Convert #Str
  RootVolume vg0 Vwi-a-t---   10.00g mythinpool1.36
   0
  [lvol0_pmspare]vg0 ewi---2.00g
  1
  mythinpool vg0 twi-aot--- <175.77g   0.08   0.79
  1
  [mythinpool_tdata] vg0 Twi-ao <175.77g
  2
  [mythinpool_tmeta] vg0 ewi-ao2.00g
  1

# dmsetup table
vg0-mythinpool: 0 368607232 linear 252:2 0
vg0-RootVolume: 0 20971520 thin 252:2 1
vg0-mythinpool-tpool: 0 368607232 thin-pool 252:0 252:1 1024 71993 1
skip_block_zeroing
vg0-mythinpool_tdata: 0 368607232 striped 2 8 254:16 4458496 254:32 264192
vg0-mythinpool_tmeta: 0 4194304 linear 254:16 188762112
```

As you can see, only "mythinpool_tdata" LV has 2 stripes. Is that OK?
If I want to benefit performance from stripes, will it works for me? Or,
should I create dataLV, metadata LV, thinpool and thin LV using
step-by-step way
and specify "--stripes 2" in every steps?

Besides, is there anything I should take care of to extend the VG/thin-pool
with *striped thin-LV*
when out of space?

Any suggestion would be very appreciated, thanks in advance!

Regards,
Eric Ren
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Unsync-ed LVM Mirror

[Eric Ren]

Hi,

On 02/05/2018 03:42 PM, Liwei wrote:

Hi Eric,
    Thanks for answering! Here are the details:

# lvm version
  LVM version:     2.02.176(2) (2017-11-03)
  Library version: 1.02.145 (2017-11-03)
  Driver version:  4.37.0
  Configuration:   ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=${prefix}/include --mandir=${prefix}/share/man 
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu 
--libexecdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --exec-prefix= 
--bindir=/bin --libdir=/lib/x86_64-linux-gnu --sbindir=/sbin 
--with-usrlibdir=/usr/lib/x86_64-linux-gnu --with-optimisation=-O2 
--with-cache=internal --with-clvmd=corosync --with-cluster=internal 
--with-device-uid=0 --with-device-gid=6 --with-device-mode=0660 
--with-default-pid-dir=/run --with-default-run-dir=/run/lvm 
--with-default-locking-dir=/run/lock/lvm --with-thin=internal 
--with-thin-check=/usr/sbin/thin_check 
--with-thin-dump=/usr/sbin/thin_dump 
--with-thin-repair=/usr/sbin/thin_repair --enable-applib 
--enable-blkid_wiping --enable-cmdlib --enable-cmirrord 
--enable-dmeventd --enable-dbus-service --enable-lvmetad 
--enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-lvmpolld 
--enable-notify-dbus --enable-pkgconfig --enable-readline 
--enable-udev_rules --enable-udev_sync


# uname -a
Linux dataserv 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) 
x86_64 GNU/Linux


Sorry, I'm not sure if this the root cause of your issue, without 
testing myself. If you have interest to

have a try, you can revert

cd15fb64ee56192760ad5c1e2ad97a65e735b18b (Revert "dm mirror: use all 
available legs on multiple failures")


and try my patch in https://patchwork.kernel.org/patch/9808897/


The "reverting" fix for the crash issue is in 4.14.0 kernel.
'""
╭─eric@ws ~/workspace/linux  ‹master›
╰─$ git log --grep "Revert \"dm mirror: use all available legs on 
multiple failures\""


commit cd15fb64ee56192760ad5c1e2ad97a65e735b18b
Author: Mike Snitzer <snit...@redhat.com>
Date:   Thu Jun 15 08:39:15 2017 -0400

    Revert "dm mirror: use all available legs on multiple failures"

    This reverts commit 12a7cf5ba6c776a2621d8972c7d42e8d3d959d20.

╭─eric@ws ~/workspace/linux  ‹master›
╰─$ git describe cd15fb64ee56192760ad5c1e2ad97a65e735b18b
v4.12-rc5-2-gcd15fb64ee56
"""

Eric



Warm regards,
Liwei

On 5 Feb 2018 15:27, "Eric Ren" <z...@suse.com <mailto:z...@suse.com>> 
wrote:


Hi,

Your LVM version and kernel version please?

like:
""""
# lvm version
  LVM version: 2.02.177(2) (2017-12-18)
  Library version: 1.03.01 (2017-12-18)
  Driver version:  4.35.0

# uname -a
Linux sle15-c1-n1 4.12.14-9.1-default #1 SMP Fri Jan 19 09:13:51
UTC 2018 (849a2fe) x86_64 x86_64 x86_64 GNU/Linux
"""

Eric

On 02/03/2018 05:43 PM, Liwei wrote:

Hi list,
     I had a LV that I was converting from linear to mirrored (not
raid1) whose source device failed partway-through during the
initial
sync.

     I've since recovered the source device, but it seems like the
mirror is still acting as if some blocks are not readable? I'm
getting
this in my logs, and the FS is full of errors:

[  +1.613126] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.000278] device-mapper: raid1: Primary mirror (253:25) failed
while out-of-sync: Reads may fail.
[  +0.085916] device-mapper: raid1: Mirror read failed.
[  +0.196562] device-mapper: raid1: Mirror read failed.
[  +0.000237] Buffer I/O error on dev dm-27, logical block
5371800560,
async page read
[  +0.592135] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.082882] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.246945] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.107374] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.083344] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.114949] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.085056] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.203929] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.157953] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +3.065247] recovery_complete: 23 callbacks suppressed
[  +0.01] device-mapper: raid1: Unable to read primary mirror
duri

Re: [linux-lvm] Unsync-ed LVM Mirror

[Eric Ren]

Hi,

Your LVM version and kernel version please?

like:

# lvm version
  LVM version: 2.02.177(2) (2017-12-18)
  Library version: 1.03.01 (2017-12-18)
  Driver version:  4.35.0

# uname -a
Linux sle15-c1-n1 4.12.14-9.1-default #1 SMP Fri Jan 19 09:13:51 UTC 
2018 (849a2fe) x86_64 x86_64 x86_64 GNU/Linux

"""

Eric

On 02/03/2018 05:43 PM, Liwei wrote:

Hi list,
 I had a LV that I was converting from linear to mirrored (not
raid1) whose source device failed partway-through during the initial
sync.

 I've since recovered the source device, but it seems like the
mirror is still acting as if some blocks are not readable? I'm getting
this in my logs, and the FS is full of errors:

[  +1.613126] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.000278] device-mapper: raid1: Primary mirror (253:25) failed
while out-of-sync: Reads may fail.
[  +0.085916] device-mapper: raid1: Mirror read failed.
[  +0.196562] device-mapper: raid1: Mirror read failed.
[  +0.000237] Buffer I/O error on dev dm-27, logical block 5371800560,
async page read
[  +0.592135] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.082882] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.246945] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.107374] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.083344] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.114949] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.085056] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.203929] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.157953] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +3.065247] recovery_complete: 23 callbacks suppressed
[  +0.01] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.128064] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.103100] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.107827] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.140871] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.132844] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.124698] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.138502] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.117827] device-mapper: raid1: Unable to read primary mirror
during recovery
[  +0.125705] device-mapper: raid1: Unable to read primary mirror
during recovery
[Feb 3 17:09] device-mapper: raid1: Mirror read failed.
[  +0.167553] device-mapper: raid1: Mirror read failed.
[  +0.000268] Buffer I/O error on dev dm-27, logical block 5367765816,
async page read
[  +0.135138] device-mapper: raid1: Mirror read failed.
[  +0.000238] Buffer I/O error on dev dm-27, logical block 5367765816,
async page read
[  +0.000365] device-mapper: raid1: Mirror read failed.
[  +0.000315] device-mapper: raid1: Mirror read failed.
[  +0.000213] Buffer I/O error on dev dm-27, logical block 5367896888,
async page read
[  +0.000276] device-mapper: raid1: Mirror read failed.
[  +0.000199] Buffer I/O error on dev dm-27, logical block 5367765816,
async page read

 However, if I take down the destination device and restart the LV
with --activateoption partial, I can read my data and everything
checks out.

 My theory (and what I observed) is that lvm continued the initial
sync even after the source drive stopped responding, and has now
mapped the blocks that it 'synced' as dead. How can I make lvm retry
those blocks again?

 In fact, I don't trust the mirror anymore, is there a way I can
conduct a scrub of the mirror after the initial sync is done? I read
about --syncaction check, but seems like it only notes the number of
inconsistencies. Can I have lvm re-mirror the inconsistencies from the
source to destination device? I trust the source device because we ran
a btrfs scrub on it and it reported that all checksums are valid.

 It took months for the mirror sync to get to this stage (actually,
why does it take months to mirror 20TB?), I don't want to start it all
over again.

Warm regards,
Liwei

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

Hi David,


IIRC, you mean we can consider to use cluster raid1 as the underlaying DM
target to support pvmove
used in cluster, since currect pvmove is using mirror target now?

That's what I imagined could be done, but I've not thought about it in
detail.  IMO pvmove under a shared LV is too complicated and not worth
doing.


Very true.




By the way, another thing I'd to ask about:   Do we really want to drop
the concept of clvm?

 From my understanding, lvmlockd is going to replace only "clvmd" daemon,
not clvm in exact.  clvm is apparently short for cluster/cluster-aware
LVM, which is intuitive naming. I see clvm as an abstract concept, which
is consisted of two pieces: clvmd and cmirrord. IMHO, I'd like to see
the clvm concept remains, no matter what we deal with the clvmd and
cmirrord. It might be good for user or documentation to digest the
change :)

Thank you for pointing out the artifice in naming here, it has long
irritated me too.  There is indeed no such thing as "clvm" or "HA LVM",
and I think we'd be better off to ban these terms completely, at least at
the technical level.  (Historically, I suspect sales/marketing had a role
in this mess by wanting to attach a name to something to sell.)

Hha, like cluster MD raid.


If the term "clvm" survives, it will become even worse IMO if we expand it
to cover cases not using "clvmd".  To me it's all just "lvm", and I don't
see why we need any other names.

It looks like people need a simple naming to distinguish the usage scenario:
local and cluster.

Thanks,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

Hi David,

On 01/09/2018 11:42 PM, David Teigland wrote:

On Tue, Jan 09, 2018 at 10:42:27AM +0800, Eric Ren wrote:

I've tested your patch and it works very well.  Thanks very much.

Could you please consider to push this patch upstream?

OK


Thanks very  much! So, can we update the `man 8 lvmlockd` to remove the 
below limitation

on lvresize?

"""
limitations of lockd VGs
...
  · resizing an LV that is active in the shared mode on multiple hosts
"""




Also, Is this the same case for pvmove as lvresize? If so, can we also
work out a similar patch for pvmove?

Running pvmove on an LV active on multiple hosts could be allowed with the
same kind of patch.  However, it would need to use cmirror which we are


OK, I see.


trying to phase out; the recent cluster raid1 has a more promising future.


My understanding is:

if cluster raid1 is used as PV, data is replicated and data migration is 
nearly equivalent
to replace disk. However, in scenario PV is on raw disk, pvmove is very 
handy for data migration.


IIRC, you mean we can consider to use cluster raid1 as the underlaying 
DM target to support pvmove

used in cluster, since currect pvmove is using mirror target now?


So I think cmirror should be left in the clvm era and not brought forward.


By the way, another thing I'd to ask about:   Do we really want to drop 
the concept of clvm?


From my understanding, lvmlockd is going to replace only "clvmd" 
daemon, not clvm in exact.
clvm is apparently short for cluster/cluster-aware LVM, which is 
intuitive naming. I see clvm
as an abstract concept, which is consisted of two pieces: clvmd and 
cmirrord. IMHO, I'd like to
see the clvm concept remains, no matter what we deal with the clvmd and 
cmirrord. It might

be good for user or documentation to digest the change :)

Regards,
Eric




___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

Hi David,

On 01/04/2018 05:06 PM, Eric Ren wrote:

David,

On 01/03/2018 11:07 PM, David Teigland wrote:

On Wed, Jan 03, 2018 at 11:52:34AM +0800, Eric Ren wrote:

1. one one node: lvextend --lockopt skip -L+1G VG/LV

 That option doesn't exist, but illustrates the point that some 
new
 option could be used to skip the incompatible LV locking in 
lvmlockd.
Hmm, is it safe to just skip the locking while the LV is active on 
other

node?
Is there somewhere in the code to avoid concurrent lvm command to 
execute

at the same time?

The VG lock is still used to protect the VG metadata change. The LV lock
doesn't protect anything per se, it just represents that lvchange has
activated the LV on this host.  (The LV lock does not represent the
suspended/resumed state of the dm device either, as you suggested 
above.)


I see, thanks for you explanation!

I'll send a simple patch to skip the lv lock to try this.


I've tested your patch and it works very well.  Thanks very much.


Could you please consider to push this patch upstream? Also, Is this the 
same case
for pvmove as lvresize? If so, can we also work out a similar patch for 
pvmove?


Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

David,

On 01/03/2018 11:07 PM, David Teigland wrote:

On Wed, Jan 03, 2018 at 11:52:34AM +0800, Eric Ren wrote:

1. one one node: lvextend --lockopt skip -L+1G VG/LV

 That option doesn't exist, but illustrates the point that some new
 option could be used to skip the incompatible LV locking in lvmlockd.

Hmm, is it safe to just skip the locking while the LV is active on other
node?
Is there somewhere in the code to avoid concurrent lvm command to execute
at the same time?

The VG lock is still used to protect the VG metadata change.  The LV lock
doesn't protect anything per se, it just represents that lvchange has
activated the LV on this host.  (The LV lock does not represent the
suspended/resumed state of the dm device either, as you suggested above.)


I see, thanks for you explanation!

I'll send a simple patch to skip the lv lock to try this.


I've tested your patch and it works very well.  Thanks very much.

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

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 less common than a local fs.

In the general case, it's not safe to assume that an LV can be modified by
one node while it's being used by others, even when all of them hold
shared locks on the LV.  You'd want to prevent that in general.
Exceptions exist, but whether an exception is ok will likely depend on
what the specific change is, what application is using the LV, whether
that application can tolerate such a change.

One (perhaps the only?) valid exception I know about is extending an LV
while it's being used under a cluster fs (any cluster fs?)


The only concrete scenario I can think of is also cluster fs, like OCFS2,
tunefs.ocfs2 can enlarge the FS to use all the device space online.


(In reference to your later email, this is not related to lock queueing,
but rather to basic ex/sh lock incompatibility, and when/how to allow
exceptions to that.)
I thought the procedures to allow lvresize is like below if the LV is 
used by cluster FS:


Assume the LV is active with "sh" lock on multiple nodes (node1 and node2),
and we  lvextend on node1:

- node1:  the "sh" lock on r1 (the LV resource) needs to up convert: 
"sh" -> "ex";
- node2: on behalf of the BAST, the "sh" lock on r1needs to down 
convert: "sh" -> "nl",

  which means the LV should be suspended;
- node1: on receiving AST (get "ex" lock), lvresize is allowed;

After the completion of lvresize,  the original lock state should be 
restored on every node,

meanwhile the latest metadata can be refreshed, maybe like below:

- node1: restore the original lock mode, "ex" -> "sh", the metadata 
version will be increased,

  so that request to update metadata can be sent to other nodes;
- node2: on receiving request, "nl" -> "sh", then to refresh the 
metadata from disk;




The simplest approach I can think of to allow lvextend under a cluster fs
would be a procedure like:


If there is a simple approach, I think it maybe worth a try.



1. one one node: lvextend --lockopt skip -L+1G VG/LV

That option doesn't exist, but illustrates the point that some new
option could be used to skip the incompatible LV locking in lvmlockd.


Hmm, is it safe to just skip the locking while the LV is active on other 
node?

Is there somewhere in the code to avoid concurrent lvm command to execute
at the same time?



2. on each node: lvchange --refresh VG/LV

This updates dm on each node with the new device size.

3. gfs2_grow VG/LV or equivalent

At this point the fs on any node can begin accessing the new space.

It would be great.

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

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 lock queueing.
 * Eventually we could enhance this to take advantage of lock
 * queueing when available (i.e. for the dlm).
"""

Is it the reason why lvmlockd has limitation on lvresize with "sh" lock
because lvmlockd cannot up convert "sh" to "ex" to perform lvresize command?

Regards,
Eric

On 12/28/2017 06:42 PM, Eric Ren wrote:

Hi David,

I see there is a limitation on lvesizing the LV active on multiple node.

From `man lvmlockd`:


"""
limitations of lockd VGs
...
* resizing an LV that is active in the shared mode on multiple hosts
"""

It seems a big limitation to use lvmlockd in cluster:

"""
c1-n1:~ # lvresize -L-1G vg1/lv1
  WARNING: Reducing active logical volume to 1.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vg1/lv1? [y/n]: y
  LV is already locked with incompatible mode: vg1/lv1
"""

Node "c1-n1" is the last node having vg1/lv1 active on it.
Can we change the lock mode from "shared" to "exclusive" to
lvresize without having to deactivate the LV on the last node?

It will reduce the availability if we have to deactivate LV on all
nodes to resize. Is there plan to eliminate this limitation in the
near future?

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Migrate volumes to new laptop

[Eric Ren]

Hi,

Not sure if you are looking for vgexport/vgimport (man 8 vgimport)?

Eric

On 12/21/2017 07:36 PM, Boyd Kelly wrote:

Hi,
I've searched hi/low and not found a howto or general suggestions for 
migrating volume groups from an old to new laptop.  I've found mostly 
server scenarios for replacing bad disks etc.  But shouldn't this be a 
relatively straightforward process using an external usb drive?  I 
would assume booting from a rescue cd/usb to start the process?   Any 
suggestions on general steps or link to some more info much appreciated.


Boyd
--

Sent from my dual sim Moto X Play with 128 G external memory, 21 MP 
camera, 1080x1920 IPS Display bought in Paris for 300 CAD.  LOL




___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] lvmlockd: about the limitation on lvresizing the LV active on multiple nodes

[Eric Ren]

Hi David,

I see there is a limitation on lvesizing the LV active on multiple node. 

From `man lvmlockd`:


"""
limitations of lockd VGs
...
* resizing an LV that is active in the shared mode on multiple hosts
"""

It seems a big limitation to use lvmlockd in cluster:

"""
c1-n1:~ # lvresize -L-1G vg1/lv1
  WARNING: Reducing active logical volume to 1.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vg1/lv1? [y/n]: y
  LV is already locked with incompatible mode: vg1/lv1
"""

Node "c1-n1" is the last node having vg1/lv1 active on it.
Can we change the lock mode from "shared" to "exclusive" to
lvresize without having to deactivate the LV on the last node?

It will reduce the availability if we have to deactivate LV on all
nodes to resize. Is there plan to eliminate this limitation in the
near future?

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] lvmlockd manpage: prevent concurrent activation of logical volumes?

[Eric Ren]

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

LV on multiple nodes?

What I interpret from it is:

with clvmd, 'vgchange/lvchange -ay' activates the LV on every node in a 
shot.

But with lvmlockd, one needs to perform:

- start the lockspace
vgchange --lockstart vg1

- vgchange -ay vg1
The LVs in vg1 will only be activated on this node.

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Shared VG, Separate LVs

[Eric Ren]

Hi,



/"I noticed you didn't configure LVM resource agent to manage your 
VG's (de)activation task,
not sure if it can always work as expect, so have more exceptional 
checking :)"

/

             Strangely the Pacemaker active-passive configuration 
example shows VG controlled by Pacemaker, while the active-active one 
does not. I have taken the active-active configuration for Pacemaker 
and created 2 LVs, then instead of formatting it using the GFS2 
clustered filesystem, I used normal XFS and made sure that it is 
mounted only on one node at a time. (lv01 on node 2, lv02 on node2)


https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/global_file_system_2/ch-clustsetup-gfs2

             I can see the clustered VG and LVs as soon 
ocf:heartbeat:clvm is started.


Is there anything I am missing here?


Good. "clvm" will activate all VGs by default. If you have more than one 
VG in your cluster,  you may want to
activate/deactivate one VG for each group of "vg" and "xfs", then you 
may need to look at LVM for each VG:


https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/LVM

Eric
___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] lvmlockd: how to convert lock_type from sanlock to dlm?

[Eric Ren]

David,


First you'll need this recent fix:
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=f611b68f3c02b9af2521d7ea61061af3709fe87c

--force was broken at some point, and the option is now --lockopt force.


Thanks!


To change between lock types, you are supposed to be able to change to a
local VG, then from local to the other lock type.  The man page sections:

   changing a lockd VG to a local VG
   changing a local VG to a lockd VG

But it looks like a fix is needed in those instructions.  I believe
"vgchange --lock-type none " needs to include --lockopt force.
If you could verify this for me, I'll update the man page.


It works! I did as the following:

"""
sle15-c1-n1:~ # vgs
  Reading VG vg1 without a lock.
  VG  #PV #LV #SN Attr   VSize  VFree
  vg1   1   1   0 wz--ns 19.97g 18.72g
sle15-c1-n1:~ # vgchange --lock-type none vg1
  Cannot access VG vg1 due to failed lock.
sle15-c1-n1:~ # vgchange --lock-type none --lockopt force vg1
Forcibly change VG lock type to none? [y/n]: y
  Volume group "vg1" successfully changed
sle15-c1-n1:~ # vgchange --lock-type dlm vg1
  Volume group "vg1" successfully changed
sle15-c1-n1:~ # vgs
  Reading VG vg1 without a lock.
  VG  #PV #LV #SN Attr   VSize  VFree
  vg1   1   1   0 wz--ns 19.97g 18.72g
sle15-c1-n1:~ # vgs -o+lock_type
  Reading VG vg1 without a lock.
  VG  #PV #LV #SN Attr   VSize  VFree  LockType
  vg1   1   1   0 wz--ns 19.97g 18.72g dlm
sle15-c1-n1:~ # vgchange --lockstart
  VG vg1 starting dlm lockspace
  Starting locking.  Waiting until locks are ready...
sle15-c1-n1:~ # lvs
  LV   VG  Attr   LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync 
Convert

  lv1  vg1 -wi--- 1.00g
"""

Thanks,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] lvmlockd: how to convert lock_type from sanlock to dlm?

[Eric Ren]

Hello David,

On my testing cluster,  the lvmlockd was firstly used with sanlock and 
everything was OK.
After some play, I want to change the "sanlock" lock_type of a VG into 
"dlm" locktype.


With dlm_controld running, I tried as following, but still failed.

1.  Performed as the "Changing dlm cluster name" section of `man lvmlockd`:

    # dlm_tool ls // no lockspace available
    # vgs
       Reading VG vg1 without a lock.
  VG  #PV #LV #SN Attr   VSize  VFree
      vg1   1   1   0 wz--ns 19.97g 18.72g
    # vgchange --lock-type none --force vg1   // the cmd comes from 
`man lvmlockd`

  Command does not accept option: --force.

2. Tried with 'global/locking_type=0':

# vgchange --config 'global/locking_type=0' --lock-type dlm vg1
  WARNING: Locking disabled. Be careful! This could corrupt your metadata.
  ERROR: configuration setting use_lvmlockd cannot be used with 
clustered locking_type 3.


The error message is strange because the locking_type=0 in the command 
line and locking_type=1

in lvm.conf.

Not sure if it's a real problem or am doing something wrong?

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] When and why vgs command can change metadata and incur old metadata to be backed up?

[Eric Ren]

Hi Alasdair,


Very simply if the metadata the command has just read in does not match
the last backup stored in the local filesystem and the process is able
and configured to write a new backup.

The command that made the metadata change might not have written a
backup if it crashed, was configured not to write backups, was running
with the filesystem readonly (e.g. booted into a recovery mode), ran on
a different node in a cluster, ran as part of an installer that chose
not to give you any metadata backups, performed metadata recovery etc.
(Plus an old release had a bug where the checking went wrong and it
made a backup every time even though nothing had actually changed.)


Can you still recall the fix commit for that bug? I recently encountered 
a similar

problem on 2.02.98. Thanks in advance.

Thanks,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] Does cmirror can tolerate one faulty PV?

[Eric Ren]

Hi all,

I performed a fault tolerance testing on cmirrored LV in cluster with 
lvm2-2.02.98.


The result really surprises me: a cmirrored LV cannot continue to work 
after disabling

its one leg PV. Is this a known issue? Or am I doing something wrong?

The steps follows:

# clvmd and cmirrord started...
# vgcreate vg1 /dev/sda /dev/sdb
# lvcreate -L1G -n lv1 --mirrorlog mirrored vg1 /dev/sda /dev/sdb
# dd if=/dev/zero of=/dev/vg1/lv1 bs=1k count=1000    ===> OK
# lvchange -an vg1/lv1
# echo 1 > /sys/block/sdb/device/delete   ==> disable one leg

# lvchange -ay --partial vg1/lv1

# dd if=/dev/zero of=/dev/vg1/lv1 bs=1k count=1000   ===> stuck forever
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C

The following log repeats while dd command is stuck:

"""
Oct 31 13:39:37 sa kernel: [316278.368081] device-mapper: 
dm-log-userspace: [NZ8pEil9] Request timed out: [9/178486] - retrying
Oct 31 13:39:37 sa kernel: [316278.448069] device-mapper: 
dm-log-userspace: [NZ8pEil9] Request timed out: [15/178497] - retrying
Oct 31 13:39:52 sa kernel: [316293.368081] device-mapper: 
dm-log-userspace: [NZ8pEil9] Request timed out: [9/178498] - retrying


"""

Thanks,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] When and why vgs command can change metadata and incur old metadata to be backed up?

[Eric Ren]

Hi all,

> 
> Interesting. Eric, can you show the *before* and *after* vgs textual
> metadata (you should find them in /etc/lvm/archive)?
> 

Ah, I think no need to show the archives now. Alasdair and David have
given us a very good explanation, thanks for them!

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[linux-lvm] When and why vgs command can change metadata and incur old metadata to be backed up?

[Eric Ren]

Hi all,

Sometimes, I see the following message in the VG metadata backups under 
/etc/lvm/archive:


"""
contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'vgs'"
"""

I'm wondering when and why the new backups will be created by reporting 
command like vgs?


Thanks in advance!
Eric


___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Shared VG, Separate LVs

[Eric Ren]

Hi,

On 10/13/2017 06:40 PM, Indivar Nair wrote:

Thanks Eric,

I want to keep a single VG so that I can get the bandwidth (LVM 
Striping) of all the disks (PVs)

  PLUS
the flexibility to adjust the space allocation between both LVs. Each 
LV will be used by  different departments. With 1 LV on different 
hosts, I can distribute the Network Bandwidth too.

I would also like to take snapshots of each LV before backing up.

I have been reading more about CLVM+Pacemaker options.
I can see that it is possible to have the same VG activated on 
multiple hosts for a GFSv2 filesystem.
In which case, it is the same PVs, VG and LV getting activated on all 
hosts.


OK! It sounds reasonable.



In my case, we will have the same PVs and VG activated on both hosts, 
but LV1 on Host01 and LV2 on Host02. I paln to use ext4 or XFS 
filesystems.


Is there some possibility that it would work?


As said in the last mail, the new resource agent [4] will probably work 
for you, but I didn't test this case yet. It's easy to have a try - the 
RA is just shell
script, you can just copy LVM-activate to 
/usr/lib/ocf/resource.d/heartbeat/ (assume you've installed 
resource-agents package), and then configure
"clvm + LVM-activate" for pacemaker [5]. Please report back if it 
doesn't work for you.


The LVM-activate RA is WIP. We are thinking if we should merge it into 
the old LVM RA. So it may changes at any time.


[5] 
https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_clvm_config.html






[1]
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/clvm

[2]
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/LVM

[3]
https://www.redhat.com/archives/linux-lvm/2017-January/msg00025.html

[4] https://github.com/ClusterLabs/resource-agents/pull/1040
\



Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Reserve space for specific thin logical volumes

[Eric Ren]

Hi David and Zdenek,

On 09/12/2017 01:41 AM, David Teigland wrote:

[...snip...]

Hi Eric, this is a good question.  The lvm project has done a poor job at
this sort of thing.  A new homepage has been in the works for a long time,
but I think stalled in the review/feedback stage.  It should be unblocked
soon.  I agree we should figure something out for communicating about
ongoing or future work (I don't think bugzilla is the answer.)

Good news! Thanks very much for you both giving such kind replies :)

Regards,
Eric

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] clvm: failed to activate logical volumes sometimes

[Eric Ren]

Hi!
On 04/20/2017 04:29 PM, emmanuel segura wrote:

maybe you are using an old clvm version, I rember that in the new
version you don't need to execute any command on the secondary node.

Thanks for your reply! Yes, I don't need to execute any command on any
remote node. But, in such case, we need "clvmd -R" on one of the nodes.

BTW, my versions:
lvm2-clvm-2.02.120-72.8.x86_64
lvm2-2.02.120-72.8.x86_64

Regards,
Eric


2017-04-20 10:06 GMT+02:00 Eric Ren <z...@suse.com>:

Hi!

This issue can be replicated by the following steps:
1. setup two-node HA cluster with dlm and clvmd RAs configured;
2. prepare a shared disk through iscsi, named "sdb" for example;

3. execute lvm cmds on n1:
lvm2dev1:~# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created
lvm2dev1:~ # vgcreate vg1 /dev/sdb
 Clustered volume group "vg1" successfully created
lvm2dev1:~ # lvcreate -l100%VG -n lv1 vg1
 Logical volume "lv1" created.
lvm2dev1:~ # lvchange -an vg1/lv1

4. disconnect shared iscsi disk on n2;
5. to activate vg1/lv1 on n1:
lvm2dev1:~ # lvchange -ay vg1/lv1
 Error locking on node UNKNOWN 1084783200: Volume group for uuid not
found: TG0VguoR1HxSO1OPA0nk737FJSQTLYAMKV2M20cfttItrRnJetTZmKxtKs3a88Ri

6. re-connect shared disk on n2;
7. execute `clvmd -R` on n1; and then I can activate lv1 successfully.

In local mode, lvm will make a full scan on disks each time when lvmetad is
disable. As we know,
lvmetad is also disable when clvm is in use, so that  device cache can not
be refreshed automatically
when device is added or removed. We can solve this issue by executing "clvmd
-R" manually. But,
in some auto scripts, it's boring to put "clvmd -R" before some lvm commands
everywhere.

So, is there an option to enable full scan every time when lvm is invoked in
cluster scenario?
Thanks in advance:)

Regards,
Eric

On 04/14/2017 06:27 PM, Eric Ren wrote:

Hi!

In cluster environment, lvcreate/lvchange may fail to activate logical
volumes sometimes.

For example:

# lvcreate -l100%VG -n lv001 clustermd
Error locking on node a52cbcb: Volume group for uuid not found:
SPxo6WiQhEJWDFyeul4gKYX2bNDVEsoXRNfU3fI5TI9Pd3OrIEuIm8jGtElDJzEy
Failed to activate new LV.

The log file for this failure is attached. My thoughts on this issue
follows, for example on two nodes:
n1:
===
#lvchange -ay vg/lv1
...
clvmd will ask for peer daemon on n2
to activate lv1 as well

n2:
===
lvm need to find lv1 and the PVs for lv1,
in device cache which aims to avoid frequent scan all
disks. But if the PV(s) might not be available
in device cache, it responses n1 with errors

We found that 'clvmd -R' can be a workaround before activating LV, because
what "clvmd -R" is to refresh device cache on every node as its commit
message said:
===
commit 13583874fcbdf1e63239ff943247bf5a21c87862
Author: Patrick Caulfield <pcaul...@redhat.com>
Date:   Wed Oct 4 08:22:16 2006 +

  Add -R switch to clvmd.
  This option will instruct all the clvmd daemons in the cluster to
reload their device cache
==

I think the reason why clvm doesn't refresh device cache every time before
activating LV,
is to avoid scanning all disks frequently.

But, I'm not sure if I understand this issue correctly, will appreciate
much if someone can
help.

Regards,
Eric




___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/





___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] clvm: failed to activate logical volumes sometimes

[Eric Ren]

Hi!

This issue can be replicated by the following steps:
1. setup two-node HA cluster with dlm and clvmd RAs configured;
2. prepare a shared disk through iscsi, named "sdb" for example;

3. execute lvm cmds on n1:
lvm2dev1:~# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created
lvm2dev1:~ # vgcreate vg1 /dev/sdb
Clustered volume group "vg1" successfully created
lvm2dev1:~ # lvcreate -l100%VG -n lv1 vg1
Logical volume "lv1" created.
lvm2dev1:~ # lvchange -an vg1/lv1

4. disconnect shared iscsi disk on n2;
5. to activate vg1/lv1 on n1:
lvm2dev1:~ # lvchange -ay vg1/lv1
Error locking on node UNKNOWN 1084783200: Volume group for uuid not found: 
TG0VguoR1HxSO1OPA0nk737FJSQTLYAMKV2M20cfttItrRnJetTZmKxtKs3a88Ri


6. re-connect shared disk on n2;
7. execute `clvmd -R` on n1; and then I can activate lv1 successfully.

In local mode, lvm will make a full scan on disks each time when lvmetad is 
disable. As we know,
lvmetad is also disable when clvm is in use, so that  device cache can not be refreshed 
automatically

when device is added or removed. We can solve this issue by executing "clvmd 
-R" manually. But,
in some auto scripts, it's boring to put "clvmd -R" before some lvm commands 
everywhere.

So, is there an option to enable full scan every time when lvm is invoked in 
cluster scenario?
Thanks in advance:)

Regards,
Eric

On 04/14/2017 06:27 PM, Eric Ren wrote:

Hi!

In cluster environment, lvcreate/lvchange may fail to activate logical volumes 
sometimes.

For example:

# lvcreate -l100%VG -n lv001 clustermd
   Error locking on node a52cbcb: Volume group for uuid not found: 
SPxo6WiQhEJWDFyeul4gKYX2bNDVEsoXRNfU3fI5TI9Pd3OrIEuIm8jGtElDJzEy

   Failed to activate new LV.

The log file for this failure is attached. My thoughts on this issue follows, for example 
on two nodes:

n1:
===
#lvchange -ay vg/lv1
...
clvmd will ask for peer daemon on n2
to activate lv1 as well

n2:
===
lvm need to find lv1 and the PVs for lv1,
in device cache which aims to avoid frequent scan all
disks. But if the PV(s) might not be available
in device cache, it responses n1 with errors

We found that 'clvmd -R' can be a workaround before activating LV, because
what "clvmd -R" is to refresh device cache on every node as its commit message 
said:
===
commit 13583874fcbdf1e63239ff943247bf5a21c87862
Author: Patrick Caulfield <pcaul...@redhat.com>
Date:   Wed Oct 4 08:22:16 2006 +

 Add -R switch to clvmd.
 This option will instruct all the clvmd daemons in the cluster to reload their device 
cache

==

I think the reason why clvm doesn't refresh device cache every time before 
activating LV,
is to avoid scanning all disks frequently.

But, I'm not sure if I understand this issue correctly, will appreciate much if 
someone can
help.

Regards,
Eric




___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] is it right to specify '-l' with all the free PE in VG when creating a thin pool?

[Eric Ren]

On 03/09/2017 07:46 PM, Zdenek Kabelac wrote:

[snip]


while it works when specifying '-l' this way:

# lvcreate -l 100%FREE --thinpool thinpool0 vgtest
  Logical volume "thinpool0" created.

Is this something by design? or something may be wrong?
I can replicate this on both:


Hi

Yes this is by DESIGN

When you specify '-l|-L'  you specify size of 'dataLV'  (logical size)
But then you need some more space for 'metadata' LVs (_tmeta & _pmspare)

-l100%FREE figure this automagically and reduces size a bit to fit in metadata 
LV.


Some 'future' version of lvm2 may support something like '--physicalsize' which will be 'a 
total size used for every allocation made by command).

Hi Zdenek,

Thanks a lot for your clarification!

Looks some changes to thin-pool feature make it behave differently since a 
certain version.
It worked on lvm2-2.02.98 (sles12) by specifying '-l' with all the free PE. Anyway, '-l 
100%FREE'

looks more reasonable in such case:)

Regards,
Eric



Regards

Zdenek

___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] New features for using lvm on shared storage

[Eric Ren]

Hi David!

On 01/10/2017 11:30 PM, David Teigland wrote:

On Tue, Jan 10, 2017 at 09:02:36PM +0800, Eric Ren wrote:

Hi David,

Sorry for faking this reply because I'm not in the maillist before I noticed
this email (quoted blow) you posted for a while.

I have a questions about "lvmlockd":

Besides clvmd cannot be used together with lvmetad, is there any other
main differences between "lvmetad" and "clvmd"? Do you recommend we replace
"clvmd" with "lvmetad"?

Hi, I think you're looking at the differences between lvmlockd and clvmd.
They have a completely different design and implementation, with lvmlockd
being much simpler and more obvious in what it does and how it works.
clvm was sort of designed around the old concept of a "single system
image" across a cluster, and tried hard to hide any difference between
local/shared VGs.  lvmlockd just inserts lock/unlock around disk
modifications when the VG is shared.  And as mentioned before, lvmlockd
can use sanlock which opens it up to new uses where a cluster doesn't fit.
I recommend replacing clvm with lvmlockd; I think it works better, and
clvm will eventually be phased out.

(lvmetad, the metadata caching daemon, can indeed be used with lvmlockd,
and not clvmd, but this is not a big advantage.  The metadata caching has
not turned out to be much of a benefit.)


I can always get clear answer and sufficient information of the background from 
you!

Thanks,
Eric




"""

For people using LVM (or clvm) on shared storage, I encourage you to take
a look at two recent additions that you may find to be an improvement:

1. System ID

is for static ownership of VGs by hosts:
http://man7.org/linux/man-pages/man7/lvmsystemid.7.html

The nearest equivalent to system ID in the past has been configuring
lvm.conf filters uniquely on each host.

2. lvmlockd

is for dynamically sharing VGs among hosts:
http://man7.org/linux/man-pages/man8/lvmlockd.8.html

Using lvmlockd with dlm is similar to what clvmd has done in the past.
Using lvmlockd with sanlock has no prior equivalent.

(For distribution packaging, see the "lvm2-lockd" rpm.)

Dave
"""



___
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/