[Bug 719333] Re: CLVM not locking LV's properly even when set to "exclusive"

Bug Watch Updater 719333 at bugs.launchpad.net
Fri Oct 27 14:50:28 UTC 2017


Launchpad has imported 11 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=517900.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-08-17T18:45:15+00:00 Brem wrote:

Description of problem: vgchange -a y bypasses exclusive vg/lv locks if
any


Version-Release number of selected component (if applicable):5.3


How reproducible: always


Steps to Reproduce:
1. activate exclusively a clustered VG on node 1 (vgchange -a ey VGXX)
2. on node 2, vgchange -a ey VGXX exits in error complaining about a lock (normal)
3. on node 2, vgchange -a y VGXX succeeds even if node 1 holds the exclusive lock
  
Actual results:
2. is OK, it fails
3. is permissive

Expected results:
3. should fail

Additional info:

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/0

------------------------------------------------------------------------
On 2009-09-26T18:20:22+00:00 Brem wrote:

Hello,

Any update on this case, will it be studied ?

Regards

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/1

------------------------------------------------------------------------
On 2009-09-26T22:07:45+00:00 Alasdair wrote:

But does (3) actually activate the LV on node 2 or not?  (Run 'dmsetup
info -c' on each machine.)

What 'vgchange -ay VGXX' means is 'activate all the LVs in VGXX on every
node in the cluster taking account of any restrictions defined in local
lvm configuration files on each node'.  (Run 'lvm dumpconfig' on each
machine.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/2

------------------------------------------------------------------------
On 2009-09-26T23:04:56+00:00 Brem wrote:

Yes it does.

I understand your point of view, but it looks more like a permissive
behaviour than a normal and desired one (my own opinion).

All the cluster nodes are setup with cluster locking (locking_type=3).

>From my understanding (and experience from other platforms), vgchange -a
y should not be allowed unless the lock holding node has released it
(prior vgchange -a en VGXXX one node1 then vgchange -a y one node2 [or
node1] to make it active on all nodes). Or if the holding node is dead.

Wouldn't that be safer ?

I always tend to imagine the unaware admin that gets on a cluster node
on which the VG is not active (held exclusively by another node) and
thinking he's doing the right thing activates (vgchange -a y) the VG,
and then mounts the FS.....

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/3

------------------------------------------------------------------------
On 2009-09-30T12:18:19+00:00 Brem wrote:

Hello,

Can we expect something to be done about that or do you just consider it
pointless?

I know you guys are doing a lot of improvements on LVM, and I'm not expecting a fix/enhancement asap, I just need to know if it gets considered and planned, at what term one should expect it to be done.
 
Regards.

Brem

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/4

------------------------------------------------------------------------
On 2009-09-30T16:27:35+00:00 Christine wrote:

I have managed to reproduce this on a two node cluster.

One node:

[root at fanny ~]#  vgchange -aey guest

On another:

[root at anna ~]# vgchange -ay guest
  Error locking on node anna: Volume is busy on another node
  Error locking on node anna: Volume is busy on another node
  Error locking on node anna: Volume is busy on another node
  1 logical volume(s) in volume group "guest" now active

so ONE volume gets activated and the others don't. If you do 'vgchange
-ay guest' again then all of them will be activated because the locks
have all been changed to CR by the previous command.

I have a full set of logs and am investigating.

Chrissie

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/5

------------------------------------------------------------------------
On 2009-10-01T13:55:28+00:00 Alasdair wrote:

Thanks for reporting this.  It's definitely a bug and a possible
solution is being tested.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/6

------------------------------------------------------------------------
On 2009-10-01T15:04:32+00:00 Christine wrote:

date: 2009/10/01 14:14:17;  author: ccaulfield;  state: Exp;  lines: +1 -0
Stop clvmd from automatically doing lock conversions. Now, if a lock
is granted at one mode and an attempt to convert it wthout the LCK_CONVERT
flag set then it will return errno=EBUSY.

It might break some things in other areas, but I doubt it.

Checking in WHATS_NEW;
/cvs/lvm2/LVM2/WHATS_NEW,v  <--  WHATS_NEW
new revision: 1.1286; previous revision: 1.1285
done
Checking in daemons/clvmd/lvm-functions.c;
/cvs/lvm2/LVM2/daemons/clvmd/lvm-functions.c,v  <--  lvm-functions.c
new revision: 1.69; previous revision: 1.68
done
Checking in lib/locking/locking.h;
/cvs/lvm2/LVM2/lib/locking/locking.h,v  <--  locking.h
new revision: 1.52; previous revision: 1.51

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/7

------------------------------------------------------------------------
On 2009-11-12T11:31:13+00:00 Milan wrote:

Fix in lvm2-cluster-2_02_54-1_el5.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/8

------------------------------------------------------------------------
On 2010-02-01T22:27:38+00:00 Corey wrote:

Fix verified in lvm2-2.02.56-6.el5/lvm2-cluster-2.02.56-6.el5.


Node 1:
[root at taft-01 ~]# vgchange -a ey taft
  1 logical volume(s) in volume group "taft" now active
[root at taft-01 ~]# lvs
  LV       VG         Attr   LSize   Origin Snap%  Move Log         Copy%  Convert
  LogVol00 VolGroup00 -wi-ao  58.38G                                              
  LogVol01 VolGroup00 -wi-ao   9.75G                                              
  mirror   taft       mwi-a- 500.00M                    mirror_mlog 100.00        


Node 2:
[root at taft-02 ~]# lvs
  LV       VG         Attr   LSize   Origin Snap%  Move Log         Copy%  Convert
  LogVol00 VolGroup00 -wi-ao  58.38G                                              
  LogVol01 VolGroup00 -wi-ao   9.75G                                              
  mirror   taft       mwi--- 500.00M                    mirror_mlog               
[root at taft-02 ~]# vgchange -a ey taft
  Error locking on node taft-02: Volume is busy on another node
  0 logical volume(s) in volume group "taft" now active
[root at taft-02 ~]# vgchange -a ey taft
  Error locking on node taft-02: Volume is busy on another node
  0 logical volume(s) in volume group "taft" now active
[root at taft-02 ~]# vgchange -a y taft
  Error locking on node taft-02: Volume is busy on another node
  Error locking on node taft-03: Volume is busy on another node
  Error locking on node taft-04: Volume is busy on another node
  Error locking on node taft-01: Device or resource busy
  0 logical volume(s) in volume group "taft" now active

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/9

------------------------------------------------------------------------
On 2010-03-30T09:02:12+00:00 errata-xmlrpc wrote:

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0299.html

Reply at:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/719333/comments/10


** Changed in: lvm2
       Status: Unknown => Fix Released

** Changed in: lvm2
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/719333

Title:
  CLVM not locking LV's properly even when set to "exclusive"

Status in lvm2:
  Fix Released
Status in lvm2 package in Ubuntu:
  Invalid

Bug description:
  Binary package hint: lvm2

  Hello,

  i got Ubuntu Lucid Server + openais + lvm + clvm running on a central
  storage.

  Metadata updates are distributed properly:

  root at xen1:~# vgs
    VG      #PV #LV #SN Attr   VSize   VFree
    vgsas1    1   5   0 wz--nc   1.36t   1.33t

  root at xen1:~# lvs
    LV                           VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk    vgsas1  -wi-a-   4.00g

  root at xen2:~# lvs
    LV                          VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk   vgsas1  -wi-a-   4.00g

  root at xen1:~# lvchange -an vgsas1/play1.xxx.net-disk
  root at xen1:~# lvs
    LV                           VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk    vgsas1  -wi---   4.00g

  NOW: Metadata obviously distributed correctly the xen2

  root at xen2:~# lvs
    LV                          VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk   vgsas1  -wi---   4.00g

  root at xen1:~# lvchange -aey vgsas1/play1.xxx.net-disk
  root at xen1:~# lvs
    LV                           VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk    vgsas1  -wi-a-   4.00g

  NOW: LV still shown as inactive on the second node.

  root at xen2:~# lvs
    LV                          VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk   vgsas1  -wi---   4.00g

  NOW: even better, i can activate it "exclusive" on the second node:

  root at xen2:~# lvchange -aey vgsas1/play1.xxx.net-disk
  root at xen2:~# lvs
    LV                          VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
    play1.xxx.net-disk   vgsas1  -wi-a-   4.00g

  I can even mount it from both nodes:

  root at xen2:~# mount /dev/vgsas1/play1.xxx.net-disk /mnt/
  root at xen2:~# df
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/cciss/c0d0p1     57672700   9810272  44932816  18% /
  none                    525972       268    525704   1% /dev
  none                    525972      9512    516460   2% /dev/shm
  none                    525972        72    525900   1% /var/run
  none                    525972         0    525972   0% /var/lock
  none                    525972         0    525972   0% /lib/init/rw
  /dev/mapper/vgsas1-play1.xxx.net--disk
                         4128448    754656   3164080  20% /mnt

  AND ON:

  root at xen1:~# !mou
  mount /dev/vgsas1/play1.xxx.net-disk /mnt/
  root at xen1:~# df
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/cciss/c0d0p1     24030076  14832148   7977272  66% /
  none                    525972       280    525692   1% /dev
  none                    525972      9392    516580   2% /dev/shm
  none                    525972        84    525888   1% /var/run
  none                    525972         0    525972   0% /var/lock
  none                    525972         0    525972   0% /lib/init/rw
  /dev/mapper/vgsas1-play1.xxx.net--disk
                         4128448    754656   3164080  20% /mnt

  
  If that was no test setting but 2 vm's accessing one ext3 fs simultaneously, I would be in serious trouble now!
  btw, the Clvm was recompiled against openais to get rid of cman.

  
  root at xen1:~# dpkg --list|grep lvm
  ii  clvm                                2.02.54-1ubuntu4.2                              Cluster LVM Daemon for lvm2
  ii  lvm2                                2.02.54-1ubuntu4.1                              The Linux Logical Volume Manager

  root at xen1:~# crm status
  ============
  Last updated: Tue Feb 15 14:16:39 2011
  Stack: openais
  Current DC: xen2 - partition with quorum
  Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
  2 Nodes configured, 2 expected votes
  0 Resources configured.
  ============

  Online: [ xen1 xen2 ]

  What's wrong there?

  so long,
  Bastian

To manage notifications about this bug go to:
https://bugs.launchpad.net/lvm2/+bug/719333/+subscriptions



More information about the foundations-bugs mailing list