Bug 1686539

Cloning this bug for rhel8 for test book keeping. 

I had forgotten this limitation in one of our scenarios and saw it fail, but then remembered that we had turned off a large portion of corrupted metadata recover/restore testing when in lvmlockd mode due to this limitation. 


[root@host-093 ~]# lvs -a -o +devices
  LV              VG            Attr       LSize   Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices        
  POOL            snapper_thinp twi---tz--   1.00g                                                       POOL_tdata(0)  
  [POOL_tdata]    snapper_thinp Twi-------   1.00g                                                       /dev/sdf1(1)   
  [POOL_tmeta]    snapper_thinp ewi-------   4.00m                                                       /dev/sdg1(0)   
  [lvol0_pmspare] snapper_thinp ewi-------   4.00m                                                       /dev/sdf1(0)   
  meta_swap.837   snapper_thinp -wi-a-----   4.00m                                                       /dev/sdf1(2826)
  newtmeta        snapper_thinp -wi-a----- 100.00g                                                       /dev/sda1(0)   
  newtmeta        snapper_thinp -wi-a----- 100.00g                                                       /dev/sdh1(0)   
  newtmeta        snapper_thinp -wi-a----- 100.00g                                                       /dev/sdd1(0)   
  newtmeta        snapper_thinp -wi-a----- 100.00g                                                       /dev/sdf1(257) 
  origin          snapper_thinp Vwi---tz--   1.00g POOL                                                                 
  other1          snapper_thinp Vwi---tz--   1.00g POOL                                                                 
  other2          snapper_thinp Vwi---tz--   1.00g POOL                                                                 
  other3          snapper_thinp Vwi---tz--   1.00g POOL                                                                 
  other4          snapper_thinp Vwi---tz--   1.00g POOL                                                                 
  other5          snapper_thinp Vwi---tz--   1.00g POOL                                                                 
  snap            snapper_thinp Vwi---tz--   1.00g POOL   origin                                                        

[root@host-093 ~]# lvconvert --yes --thinpool snapper_thinp/POOL --poolmetadata snapper_thinp/meta_swap.837
  Unable to swap pool metadata in VG with lock_type dlm

kernel-4.18.0-67.el8    BUILT: Sat Feb  9 08:10:47 CST 2019
lvm2-2.03.02-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
lvm2-libs-2.03.02-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
lvm2-dbusd-2.03.02-6.el8    BUILT: Fri Feb 22 04:50:28 CST 2019
lvm2-lockd-2.03.02-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
cmirror-2.03.02-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-libs-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-event-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-event-libs-1.02.155-6.el8    BUILT: Fri Feb 22 04:47:54 CST 2019
device-mapper-persistent-data-0.7.6-1.el8    BUILT: Sun Aug 12 04:21:55 CDT 2018

Let's schedule this for 8.1, it will be doable with the same capabilities that I've outlined for cachevol repair.  Specifically what's needed is the ability to take an LV (pool) offline, so that it can be safely disassembled/debugged/repaired without concern about something else trying to use it during that whole process.  While it's offline for repair and maintenance we would just disable cluster locking on it.  The main part of this solution is the maintenance-mode feature that was actually written quite a while ago but not merged:
https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-maintenance

(Before the proper feature is ready, a user would need to explicitly disable locking for the maintenance and repair commands.)

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.