'lvresize -r' being run concurrently with other VG modifications leads to inconsistent results

Issue

• When an lvresize command (including lvreduce or lvextend) in "resize file system" mode (i.e. : the -r/--resizefs flag), in parallel of other LVM commands modifying the VG (lvresize, lvremove, vgextend, etc.), the result may be unexpected.

• Example 1, extract from RHEL6 :

• We are running concurrently an lvresize command and lvremove (lvremove start a second after lvresize). We can see that the successfully deleted vgtests/c suddenly reapears after the lvresize command finishes :

[root@dhcp-26-101 ~]# lvs ; lvresize -r -L-300M vgtests/b & sleep 1 ; lvremove --force vgtests/c ; lvs ; wait ; lvs
  LV   VG      Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  Root VG01    -wi-ao----   5.47g                                             
  Swap VG01    -wi-ao---- 288.00m                                             
  a    vgtests -wi-a----- 300.00m                                             
  b    vgtests -wi-a----- 600.00m                                             
  c    vgtests -wi-a----- 600.00m                                             
[1] 12464                                                         <= lvresize -r runs in the background
fsck from util-linux-ng 2.17.2
/dev/mapper/vgtests-b: 238/151800 files (24.4% non-contiguous), 263287/614400 blocks
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mapper/vgtests-b to 307200 (1k) blocks.
  Logical volume "c" successfully removed
  LV   VG      Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  Root VG01    -wi-ao----   5.47g                                             
  Swap VG01    -wi-ao---- 288.00m                                             
  a    vgtests -wi-a----- 300.00m                                             
  b    vgtests -wi-ao---- 600.00m                                 <= lvremove successfully removed vgtests/c
The filesystem on /dev/mapper/vgtests-b is now 307200 blocks long.

  Reducing logical volume b to 300.00 MiB
  Logical volume b successfully resized
[1]+  Done                    lvresize -r -L-300M vgtests/b       <= lvresize is finished
  LV   VG      Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  Root VG01    -wi-ao----   5.47g                                             
  Swap VG01    -wi-ao---- 288.00m                                             
  a    vgtests -wi-a----- 300.00m                                             
  b    vgtests -wi-a----- 300.00m                                             
  c    vgtests -wi------- 600.00m                                  <= deleted vgtests/c suddenly reappears

• In particular, launching lvresize in concurrence (e.g. separated by 1 second in example below) leaves unmatching LV / file system size.

• Example 2, extract from RHEL5 :

• Before :

[root@vm-199 ~]# df -h /mnt/?/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/tests-a   733M  285M  411M  41% /mnt/a
/dev/mapper/tests-b   733M  285M  411M  41% /mnt/b
/dev/mapper/tests-c   590M  184M  376M  33% /mnt/c
/dev/mapper/tests-d   637M  185M  420M  31% /mnt/d
/dev/mapper/tests-e   637M  185M  420M  31% /mnt/e
/dev/mapper/tests-f    90M  5.6M   79M   7% /mnt/f
[root@vm-199 ~]# lvs tests
  LV   VG    Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  a    tests -wi-ao 756.00M
  b    tests -wi-ao 756.00M
  c    tests -wi-ao 608.00M
  d    tests -wi-ao 656.00M
  e    tests -wi-ao 656.00M
  f    tests -wi-ao  92.00M

• Unmount & resize concurrently & mount:

[root@vm-199 ~]# for LV in a b c d e ; do lvresize -r -L-400M /dev/tests/$LV & sleep 1 ; done

• After :

[root@vm-199 ~]# lvs tests
  LV   VG    Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  a    tests -wi-ao 756.00M
  b    tests -wi-ao 756.00M
  c    tests -wi-ao 608.00M
  d    tests -wi-ao 256.00M
  e    tests -wi-ao 656.00M
  f    tests -wi-ao  92.00M
[root@vm-199 ~]# df -h /mnt/?/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/tests-a   346M  285M   44M  87% /mnt/a
/dev/mapper/tests-b   346M  285M   44M  87% /mnt/b
/dev/mapper/tests-c   202M  184M  7.8M  96% /mnt/c
/dev/mapper/tests-d   249M  184M   52M  79% /mnt/d
/dev/mapper/tests-e   249M  184M   52M  79% /mnt/e
/dev/mapper/tests-f    90M  5.6M   79M   7% /mnt/f

• Result: The FS have been reduced successfully, but from LV layer, only tests-d has actually been re-sized