Bug 1270997 - auto extension of pool may require multiple reactivations before it happens when threshold is initially turned off
auto extension of pool may require multiple reactivations before it happens w...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2 (Show other bugs)
7.2
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Zdenek Kabelac
cluster-qe@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-12 17:13 EDT by Corey Marthaler
Modified: 2017-07-27 16:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2015-10-12 17:13:08 EDT
Description of problem:
I've noticed around 30-40% of the time the automatic thin pool extension doesn't work while residing on a shared volume unless I deactivate and then reactivate a second time the volume. In this case, the threshold is initially *off* and *then* turned on.

============================================================
Iteration 4 of 10 started at Mon Oct 12 15:45:40 CDT 2015
============================================================
SCENARIO - [verify_auto_extension_of_pool_w_thres_initially_off]

Create a thin snapshot and then fill it past the extend threshold, then turn on auto extend monitoring
Making pool volume
lvcreate --activate ey --thinpool POOL  --zero n -L 1G --poolmetadatasize 4M snapper_thinp

Making origin volume
lvcreate --activate ey --virtualsize 1G -T snapper_thinp/POOL -n origin

Making snapshot of origin volume
lvcreate --activate ey -k n -s /dev/snapper_thinp/origin -n auto_extension

Filling snapshot /dev/snapper_thinp/auto_extension
723+0 records in
723+0 records out
758120448 bytes (758 MB) copied, 8.74977 s, 86.6 MB/s

Now enabling thin_pool_autoextend_threshold
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
sleep 30

Deactivating origin/snap volume(s)
lvchange -an snapper_thinp/POOL

Activating origin/snap volume(s)
lvchange -ay snapper_thinp/POOL
sleep 45

thin pool doesn't appear to have been extended to 1.2*g


Version-Release number of selected component (if applicable):
3.10.0-322.el7.x86_64

lvm2-2.02.130-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
lvm2-libs-2.02.130-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
lvm2-cluster-2.02.130-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
device-mapper-1.02.107-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
device-mapper-libs-1.02.107-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
device-mapper-event-1.02.107-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
device-mapper-event-libs-1.02.107-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
device-mapper-persistent-data-0.5.5-1.el7    BUILT: Thu Aug 13 09:58:10 CDT 2015
cmirror-2.02.130-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015
sanlock-3.2.4-1.el7    BUILT: Fri Jun 19 12:48:49 CDT 2015
sanlock-lib-3.2.4-1.el7    BUILT: Fri Jun 19 12:48:49 CDT 2015
lvm2-lockd-2.02.130-2.el7    BUILT: Tue Sep 15 07:15:40 CDT 2015


How reproducible:
Sometimes
Comment 3 Corey Marthaler 2015-10-13 15:00:12 EDT
After more testing, this happens on thin pools on *non* shared VGs as well.

In these cases, after the write up to 75%+ (even with just a 70% threshold), and a monitoring restarted (lvchange --monitor y), and a reactivation, the POOL still isn't expanded some of the times.


============================================================
Iteration 2 of 50 started at Tue Oct 13 13:45:09 CDT 2015
============================================================
SCENARIO - [verify_auto_extension_of_pool_w_thres_initially_off]
Create a thin snapshot and then fill it past the extend threshold, then turn on auto extend monitoring
Making pool volume
lvcreate  --thinpool POOL  --zero y -L 1G --poolmetadatasize 4M snapper_thinp

Sanity checking pool device (POOL) metadata
examining superblock
examining devices tree
examining mapping tree
checking space map counts

Making origin volume
lvcreate  --virtualsize 1G -T snapper_thinp/POOL -n origin
lvcreate  -V 1G -T snapper_thinp/POOL -n other1
  WARNING: Sum of all thin volume sizes (2.00 GiB) exceeds the size of thin pool snapper_thinp/POOL (1.00 GiB)!
lvcreate  -V 1G -T snapper_thinp/POOL -n other2
  WARNING: Sum of all thin volume sizes (3.00 GiB) exceeds the size of thin pool snapper_thinp/POOL (1.00 GiB)!
lvcreate  -V 1G -T snapper_thinp/POOL -n other3
  WARNING: Sum of all thin volume sizes (4.00 GiB) exceeds the size of thin pool snapper_thinp/POOL (1.00 GiB)!
lvcreate  --virtualsize 1G -T snapper_thinp/POOL -n other4
  WARNING: Sum of all thin volume sizes (5.00 GiB) exceeds the size of thin pool snapper_thinp/POOL (1.00 GiB)!
lvcreate  -V 1G -T snapper_thinp/POOL -n other5
  WARNING: Sum of all thin volume sizes (6.00 GiB) exceeds the size of thin pool snapper_thinp/POOL (1.00 GiB)!
Making snapshot of origin volume
lvcreate  -k n -s /dev/snapper_thinp/origin -n auto_extension
Filling snapshot /dev/snapper_thinp/auto_extension
775+0 records in
775+0 records out
812646400 bytes (813 MB) copied, 7.58207 s, 107 MB/s
Now enabling thin_pool_autoextend_threshold
Starting monitoring again: lvchange --monitor y snapper_thinp/POOL
Deactivating origin/snap volume(s)
lvchange -an snapper_thinp/POOL
Activating origin/snap volume(s)


thin pool doesn't appear to have been extended to 1.2*g
Comment 4 Corey Marthaler 2015-10-21 12:12:08 EDT
FWIW, a full "vgchange -an; vgchange -ay" is a hack for this issue that appears to cause the extension everytime.

Note You need to log in before you can comment on or make changes to this bug.