lvmteam / lvm2 Goto Github PK

Mirror of upstream LVM2 repository

Home Page: https://gitlab.com/lvmteam/lvm2

License: GNU General Public License v2.0

Makefile 0.80% M4 0.94% Shell 18.73% C 75.52% Python 2.86% C++ 0.51% Nix 0.19% Ruby 0.02% Roff 0.13% Awk 0.01% Assembly 0.06% BitBake 0.22%

lvm2's People

Contributors

Stargazers

Watchers

lvm2's Issues

Deprecate: LVM python bindings and liblvm2app

We intend to remove support for the LVM python bindings and liblvm2app library. Users will need to find an alternate interface - for example, the more complete, supported and correct dbus interface.

Target removal date/release: ?
Alternate interfaces: ?

See also: RHBZ: https://bugzilla.redhat.com/1489590

LVS showing wrong size of data used

I encouter a problem/bug with Debian 10 and my LVM Thin just installed.
I setup my lvm with this :

umount /home
vgcreate vg_home /dev/sda2
lvcreate -l 100%FREE --thinpool pool_0_vg_home vg_home
lvcreate -V 5G --thin -n user vg_home/pool_0_vg_home
mkdir -p /home/whisper40/data/user
mkfs.ext4 /dev/vg_home/user
echo "/dev/vg_home/user /home/whisper40/data/user   ext4    defaults        0       2" >> /etc/fstab

No problem, all is working.
I add some data, ok space is growing up..

I delete the data, and.. the lvs report again the same value, the value of never decrease.
df-h report the right value 1% used, but lvs report 30% used.

If i use this command : fstrim -v /home/whisper40/data/user it updates the data value. But i don't understand what's wrong with this, it should report me all time the right value. I don't want to execute this command everytime.. that makes no sense
This is my discard mode
I already read the Discard part of this documentation : https://man7.org/linux/man-pages/man7/lvmthin.7.html

My windows machine has NVME disk
I'm running thoses commands on Debian 10 on Vmware

[lvmdbusd] Percentage Values

Currently the percentage values such as MdaPercent + DataPercent wouldn't be exposed correctly. These are always zero.

Is there any reason why the percentages aren't reported as double, if no i'd like to change them.

This has been reported over dbus.

'/com/redhat/lvmdbus1/Lv/54': {'com.redhat.lvmdbus1.Lv': {},
                                'com.redhat.lvmdbus1.LvCommon': {'Active': True,
                                                                 'AllocationPolicy': ('i',
                                                                                      'inherited'),
                                                                 'Attr': 'Vwi-a-tz--',
                                                                 'CopyPercent': 0,
                                                                 'DataPercent': 0,
                                                                 'Devices': [],
                                                                 'FixedMinor': False,
                                                                 'Health': ('-',
                                                                            'Unspecified'),
                                                                 'HiddenLvs': [],
                                                                 'IsThinPool': False,
                                                                 'IsThinVolume': True,
                                                                 'MetaDataPercent': 0,
                                                                 'MetaDataSizeBytes': 0,
                                                                 'MovePv': '/',
                                                                 'Name': 'thin_lv',
                                                                 'OriginLv': '/',
                                                                 'Path': '/dev/tonobo-top-vg/thin_lv',
                                                                 'Permissions': ('w',
                                                                                 'writable'),
                                                                 'PoolLv': '/com/redhat/lvmdbus1/ThinPool/0',
                                                                 'Roles': ['public'],
                                                                 'SegType': ['thin'],
                                                                 'SizeBytes': 3221225472,
                                                                 'SkipActivation': False,
                                                                 'SnapPercent': 0,
                                                                 'State': ('a',
                                                                           'active'),
                                                                 'SyncPercent': 0,
                                                                 'Tags': [],
                                                                 'TargetType': ('t',
                                                                                'thin'),
                                                                 'Uuid': 'O0LeqP-mnW4-27dn-fi76-utXN-oVng-AFcLC8',
                                                                 'Vg': '/com/redhat/lvmdbus1/Vg/0',
                                                                 'VolumeType': ('V',
                                                                                'thin '
                                                                                'Volume'),
                                                                 'ZeroBlocks': True}},

This is what lvs has been returned.

timmy@tonobo-top  >>> sudo lvs -o name,data_percent,metadata_lv,metadata_percent | grep thin_lv
  thin_lv   6.51

LVM2.2.03.11/daemons/lvmlockd/lvmlockd-core.c: 2* off by one errors ?

LVM2.2.03.11/daemons/lvmlockd/lvmlockd-core.c:900:8: error: Width 16 given in format string (no. 3) is larger than destination buffer 'lm_type_str[16]', use %15s to prevent overflowing it. [invalidScanfFormatWidth]

LVM2.2.03.11/daemons/lvmlockd/lvmlockd-core.c:920:8: error: Width 8 given in format string (no. 4) is larger than destination buffer 'mode[8]', use %7s to prevent overflowing it. [invalidScanfFormatWidth]

how to commit bugfix to community?

Is it OK to mail the bug description and patch to [email protected] ?

Support vgsplit on cached volumes

I'm trying vgsplit on VG containing cached volumes. The code seems okay, except the following:

_move_cache() should not move the volume if the underlying volumes were not moved.
To support cached pools, _move_cache() should go before _move_thins()

Suggested patch:

diff --git a/tools/vgsplit.c b/tools/vgsplit.c
index 02f7132a9..e163ee466 100644
--- a/tools/vgsplit.c
+++ b/tools/vgsplit.c
@@ -388,10 +388,6 @@ static int _move_cache(struct volume_group *vg_from,
 		 *        cache LVs.
 		 * Waiting for next release before fixing and enabling.
 		 */
-		log_error("Unable to split VG while it contains cache LVs");
-		return 0;
-
-		/* NOTREACHED */
 
 		if (lv_is_cache(lv)) {
 			orig = seg_lv(seg, 0);
@@ -431,7 +427,7 @@ static int _move_cache(struct volume_group *vg_from,
 				  lv->name, meta->name);
 			return 0;
 		}
-		if (!_move_one_lv(vg_from, vg_to, lvh))
+		if (is_moving && !_move_one_lv(vg_from, vg_to, lvh))
 			return_0;
 	}
 
@@ -666,13 +662,13 @@ int vgsplit(struct cmd_context *cmd, int argc, char **argv)
 	if (!(_move_snapshots(vg_from, vg_to)))
 		goto_bad;
 
+	if (!(_move_cache(vg_from, vg_to)))
+		goto_bad;
+
 	/* Move required pools across */
 	if (!(_move_thins(vg_from, vg_to)))
 		goto_bad;
 
-	if (!(_move_cache(vg_from, vg_to)))
-		goto_bad;
-
 	/* Split metadata areas and check if both vgs have at least one area */
 	if (!(vg_split_mdas(cmd, vg_from, vg_to)) && vg_from->pv_count) {
 		log_error("Cannot split: Nowhere to store metadata for new Volume Group");

lvcreate not found: device not cleared

platform:


1. 

uname -a
Linux controller7325 3.10.0-957.10.4.el7.x86_64 #1 SMP Wed Oct 21 09:27:12 CST 2020 x86_64 x86_64 x86_64 GNU/Linux

2. 

cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)

3.
lvm version
  LVM version:     2.02.180(2)-RHEL7 (2018-07-20)
  Library version: 1.02.149-RHEL7 (2018-07-20)
  Driver version:  4.37.1
  Configuration:   ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-default-dm-run-dir=/run --with-default-run-dir=/run/lvm --with-default-pid-dir=/run --with-default-locking-dir=/run/lock/lvm --with-usrlibdir=/usr/lib64 --enable-lvm1_fallback --enable-fsadm --with-pool=internal --enable-write_install --with-user= --with-group= --with-device-uid=0 --with-device-gid=6 --with-device-mode=0660 --enable-pkgconfig --enable-applib --enable-cmdlib --enable-dmeventd --enable-blkid_wiping --enable-python2-bindings --with-cluster=internal --with-clvmd=corosync --enable-cmirrord --with-udevdir=/usr/lib/udev/rules.d --enable-udev_sync --with-thin=internal --enable-lvmetad --with-cache=internal --enable-lvmpolld --enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-dmfilemapd

4.
create an shared sanlock vg:
vgcreate global_lock  /dev/mapper/mpatha --shared --metadatasize 10M


5.
[root@controller7325 ~]# pvs
  PV                 VG                Fmt  Attr PSize    PFree
  /dev/mapper/mpatha global_lock       lvm2 a--    14.98g   14.73g
  /dev/sdb           controller7325SSD lvm2 a--  <447.13g <447.13g
  /dev/sdg           controller7325HDD lvm2 a--    <5.46t       0
  /dev/sdh4          data              lvm2 a--   148.47g       0

6.
create lv:
lvcreate --name zhx --size 1g global_lock -v
    Loading table for global_lock-lvmlock (253:8).
    Suppressed global_lock-lvmlock (253:8) identical table reload.
    Suspending global_lock-lvmlock (253:8) with device flush
    Loading table for global_lock-lvmlock (253:8).
    Suppressed global_lock-lvmlock (253:8) identical table reload.
    Resuming global_lock-lvmlock (253:8).
    Archiving volume group "global_lock" metadata (seqno 15).
    Creating logical volume zhx
    Creating volume group backup "/etc/lvm/backup/global_lock" (seqno 16).
    Activating logical volume global_lock/zhx.
    activation/volume_list configuration setting not defined: Checking only host tags for global_lock/zhx.
    Creating global_lock-zhx
    Loading table for global_lock-zhx (253:9).
    Resuming global_lock-zhx (253:9).
  /dev/global_lock/zhx: not found: device not cleared
  Aborting. Failed to wipe start of new LV.
    Removing global_lock-zhx (253:9)
    Creating volume group backup "/etc/lvm/backup/global_lock" (seqno 17).
  semid 1376258: semop failed for cookie 0xd4d3570: incorrect semaphore state
  Failed to set a proper state for notification semaphore identified by cookie value 223163760 (0xd4d3570) to initialize waiting for incoming notifications.

Am I missing anything ?

lvm2 fails to build with -Wparentheses

libdm/libdm-deptree.c fails to build with -Wparentheses on Chrome OS and produces the following error,

lvm2-2.02.187-r3: libdm-deptree.c:2467:81: warning: operator '?:' has lower precedence than '+'; '+' will be evaluated first [-Wparentheses]
lvm2-2.02.187-r3: EMIT_PARAMS(pos, " %u", (seg->policy_argc + (seg->migration_threshold != 2048) ? 1 : 0) * 2);
lvm2-2.02.187-r3: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
lvm2-2.02.187-r3: libdm-deptree.c:2037:59: note: expanded from macro 'EMIT_PARAMS'
lvm2-2.02.187-r3: if ((w = dm_snprintf(params + p, paramsize - (size_t) p, str)) < 0) {
lvm2-2.02.187-r3: ^~~
lvm2-2.02.187-r3: libdm-deptree.c:2467:81: note: place parentheses around the '+' expression to silence this warning
lvm2-2.02.187-r3: EMIT_PARAMS(pos, " %u", (seg->policy_argc + (seg->migration_threshold != 2048) ? 1 : 0) * 2);
lvm2-2.02.187-r3: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
lvm2-2.02.187-r3: libdm-deptree.c:2037:59: note: expanded from macro 'EMIT_PARAMS'
lvm2-2.02.187-r3: if ((w = dm_snprintf(params + p, paramsize - (size_t) p, str)) < 0) {
lvm2-2.02.187-r3: ^~~
lvm2-2.02.187-r3: libdm-deptree.c:2467:81: note: place parentheses around the '?:' expression to evaluate it first
lvm2-2.02.187-r3: EMIT_PARAMS(pos, " %u", (seg->policy_argc + (seg->migration_threshold != 2048) ? 1 : 0) * 2);
lvm2-2.02.187-r3: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
lvm2-2.02.187-r3: libdm-deptree.c:2037:59: note: expanded from macro 'EMIT_PARAMS'
lvm2-2.02.187-r3: if ((w = dm_snprintf(params + p, paramsize - (size_t) p, str)) < 0) {
lvm2-2.02.187-r3: ^~~
lvm2-2.02.187-r3: 1 warning generated.

More details can be found at https://b.corp.google.com/issues/195062447.

10-dm.rules disable systemd .device-units on coldplug

We are using LVM2 Udev rules in embedded project (Yocto Project 3.0.1, package lvm2-udevrules from recipe lvm2_2.03.02.bb), initializing DM-devices in initramfs, but during systemd startup it thinks, that our DM-devices are invalid.

So, boot sequence is as is:

initramfs boots with only one simple program written in C
this init do some our specific initialization
init creates /dev/mapper/control with mknod(...)
init initializes required device-mapper devices by using ioctl(...) on /dev/mapper/control directly
init creates nodes for this devices in /dev/mapper/ with mknod(...)
init performs some kind of switch_root and passes control to the systemd
systemd boots normally on fully prepared filesystem
systemd runs systemd-udevd
systemd-udevd trigger environment variable SYSTEMD_READY as equal to 0
all units dev-mapper-*.device hang up, waiting for corresponding devices, but that never happens
device basically goes into boot loop

The reason of such systemd-udevd behavior are rules in 10-dm.rules. Seems they don't take into account our situation: no any kind of udev was running in initramfs, so udev database is completely absent. That's why bunch of IMPORT{db} in the 10-dm.rules don't update any variables. That's why variables DM_UDEV_RULES_VSN and DM_UDEV_PRIMARY_SOURCE_FLAG are still unset in the rule ENV{DM_UDEV_RULES_VSN}!="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable", which in it's turn completely disables the device, when it actually was properly initialized and working - rootfs depends on this devices.

On LABEL="dm_disable" variable DM_UDEV_DISABLE_OTHER_RULES_FLAG is set. And than in 99-systemd.rules it is used to set SYSTEMD_READY=0.

Proposed solution:
10-dm.rules should take into account situation, when no environment was provided at all. That is - after bunch of IMPORT{db} check sanity of at least DM_UDEV_PRIMARY_SOURCE_FLAG and DM_UDEV_RULES_VSN - check if they are set, and if not set manually DM_UDEV_PRIMARY_SOURCE_FLAG=0 (as it is add coldplug event) and DM_UDEV_RULES_VSN=1 (because what options).
99-systemd.rules seems sane...

Something like this right after loading from DB:
ENV{DM_UDEV_RULES_VSN}!="?*", ENV{DM_UDEV_RULES_VSN}="1"
ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="?*", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}="0"

MALLOC_MMAP_THRESHOLD_=0 makes systemd-cryptsetup fail

I added this line to systemd-cryptsetup service files to instruct glibc malloc() to use mmap() instead of heap:

Environment=MALLOC_MMAP_THRESHOLD_=0

But then systemd-cryptsetup refuses to start:

Sep 23 15:24:29 systemd-cryptsetup[892]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/mapper/levy-swap.
Sep 23 15:24:29 systemd-cryptsetup[892]: Couldn't create ioctl argument.
Sep 23 15:24:29 systemd-cryptsetup[892]: Cannot use device cswap, name is invalid or still in use.

The error message "Couldn't create ioctl argument." comes from device_mapper/ioctl/libdm-iface.c#L1818). The problem seems to be that mmap() (called from malloc() called from dm_zalloc() called from device_mapper/ioctl/libdm-iface.c#L1190) may fail with EAGAIN:

sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=src/cryptsetup/cryptsetup.c\nCODE_LINE=615\nCODE_FUNC=attach_luks_or_plain_or_bitlk\nSYSLOG_IDENTIFIER=systemd-cryptsetup\n", iov_len=158}, {iov_base="MESSAGE=", iov_len=
8}, {iov_base="Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/mapper/levy-swap.", iov_len=85}, {iov_base="\n", iov_len=1}], msg_iovlen=4, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 252
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7517ebd1a000
mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7517ebd10000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
brk(NULL)                               = 0x648b5b83c000
brk(0x648b5b85d000)                     = 0x648b5b83c000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
ioctl(4, DM_LIST_VERSIONS, {version=4.1.0, data_size=16384, data_start=312, flags=DM_EXISTS_FLAG} => {version=4.42.0, data_size=428, data_start=312, flags=DM_EXISTS_FLAG, ...}) = 0
munmap(0x7517ebd10000, 20480)           = 0
munmap(0x7517ebd1a000, 4096)            = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7517ebd1a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7517ebd14000
mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
brk(0x648b5b861000)                     = 0x648b5b83c000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7517ebd13000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7517ebd12000
munmap(0x7517ebd13000, 4096)            = 0
sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="PRIORITY=3\nSYSLOG_FACILITY=3\nCODE_FILE=src/shared/cryptsetup-util.c\nCODE_LINE=95\nCODE_FUNC=cryptsetup_log_glue\nSYSLOG_IDENTIFIER=systemd-cryptsetup\n", iov_len=148}, {iov_base="MESSAGE=", iov_len=8}, {iov_b
ase="Couldn't create ioctl argument.", iov_len=31}, {iov_base="\n", iov_len=1}], msg_iovlen=4, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188

I'm puzzled why mmap() for 4096 bytes or even 1M would fail, so perhaps this is a bug in glibc or kernel, but I'd like first to check if this could be a bug in lvm2.

Issue(Failed to connect to lvmetad. Falling back to device scanning) after upgrading LVM2 to 2.02.180

lvm_bootupIssue.txt

We have updated the respective package from 2.02.176 to 2.02.180. We have verified the same and booted x86_64 hardware without any issues.
But while trying to boot mips64 hardware we have started observing the below issue. Providing the snippet of the log,

executing command: vgchange -an

(status, output): (0, WARNING: Failed to connect to lvmetad. Falling back to device scanning.)
WARNING: Failed to connect to lvmetad. Falling back to device scanning.

Attached the detailed log for reference. There is no other change included other than the LVM2 update.
LVM2 Version: 2.02.176Updated LVM2 version: 2.02.180
Please share inputs on why this issue is being observed with .180 version? Please let me know if i can share any other information.

lvm cache volumes / flushing blocks

i have a cached lv and i want to extend it. afaik, i will have to remove the caching, extend the lv, and then add the caching again.

however:

lvconvert --uncache /dev/vgraid/lvraid

result in endless "flushing NNN blocks" and never finishes - same for other commands (such as lvremove vgraid/cache_data) . using lvs, i can see the following:

   LV                        VG     Attr       LSize    Pool                Origin         Data%  Meta%  Move Log Cpy%Sync Convert Devices                                                                    CacheTotalBlocks CacheUsedBlocks  CacheDirtyBlocks Type       CacheMode   
  [lvol0_pmspare]           vgraid ewi-------    2.00g                                                                            /dev/mapper/cache_data(359138)                                                                                                linear                 
  lvraid                    vgraid Cwi-aoC---   14.55t [lvraid_cache_data] [lvraid_corig] 99.99  0.58            99.32            lvraid_corig(0)                                                                      999340           999339           992494 cache      writethrough
  [lvraid_cache_data]       vgraid Cwi---C---    1.37t                                    99.99  0.58            99.32            lvraid_cache_data_cdata(0)                                                           999340           999339           992494 cache-pool writethrough
  [lvraid_cache_data_cdata] vgraid Cwi-ao----    1.37t                                                                            /dev/mapper/cache_data(0)                                                                                                     linear                 
  [lvraid_cache_data_cmeta] vgraid ewi-ao----    2.00g                                                                            /dev/mapper/cache_meta(0)                                                                                                     linear                 
  [lvraid_corig]            vgraid rwi-aoC---   14.55t                                                           100.00           lvraid_corig_rimage_0(0),lvraid_corig_rimage_1(0),lvraid_corig_rimage_2(0)                                                    raid5                  
  [lvraid_corig_rimage_0]   vgraid iwi-aor---   <7.28t                                                                            /dev/mapper/sda1_crypt(1)                                                                                                     linear                 
  [lvraid_corig_rimage_1]   vgraid iwi-aor---   <7.28t                                                                            /dev/mapper/sdb1_crypt(1)                                                                                                     linear                 
  [lvraid_corig_rimage_2]   vgraid iwi-aor---   <7.28t                                                                            /dev/mapper/sdc1_crypt(1)                                                                                                     linear                 
  [lvraid_corig_rmeta_0]    vgraid ewi-aor---    4.00m                                                                            /dev/mapper/sda1_crypt(0)                                                                                                     linear                 
  [lvraid_corig_rmeta_1]    vgraid ewi-aor---    4.00m                                                                            /dev/mapper/sdb1_crypt(0)                                                                                                     linear                 
  [lvraid_corig_rmeta_2]    vgraid ewi-aor---    4.00m                                                                            /dev/mapper/sdc1_crypt(0)                                                                                                     linear

one interesting thing i saw was that the cache_data lv is "not active":

  --- Logical volume ---
  Internal LV Name       lvraid_cache_data
  VG Name                vgraid
  LV UUID                3R19cf-WsX8-LJHA-4L9U-ytbw-x1Zo-YfU1Pl
  LV Write Access        read/write
  LV Creation host, time nasenhase, 2019-10-11 20:41:55 +0000
  LV Pool metadata       lvraid_cache_data_cmeta
  LV Pool data           lvraid_cache_data_cdata
  LV Status              NOT available
  LV Size                1.37 TiB
  Current LE             359138
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

how can i resovle this, short of copying everything off? when i do a vgcfgbackup, i get this:
vgraid_orig.txt

and if i modify it to this:
vgraid_modified.txt

the orig volume mounts fine, but it is missing data ... so apparently, something about the blocks it wants to flush is important after all.

what can i do to resolve this?

pvcreate on mounted device prints error twice

When issuing pvcreate on a device that is currently mounted, the following error appears twice:

$ sudo /dev/shm/lvm/sbin/pvcreate /dev/loop2
  Can't open /dev/loop2 exclusively.  Mounted filesystem?
  Can't open /dev/loop2 exclusively.  Mounted filesystem?

I bisected this to the following commit:
28c8e95

Steps to reproduce:

Prepare a mounted device

dd if=/dev/zero of=/dev/shm/back count=1000 bs=1024K
losetup -f --show /dev/shm/back
Take note of the loop device, say /dev/loop0
Clone the lvm2 repo
cd ./lvm2
mkdir /dev/shm/lvm
./configure --prefix=/dev/shm/lvm --with-default-system-dir=/dev/shm/lvm --with-confdir=/dev/shm/lvm
make install
sudo /dev/shm/lvm/sbin/pvcreate /dev/loop0

lv not available after reboot

lv not available after reboot，how to solve this problem？？？

After bring up, I can use “vgchange -ay vg0“ command to solve this problem manually,Is there any way to solve this problem automatically？？

LVM version:
LVM version: 2.03.10(2)-git (2020-03-26)
Library version: 1.02.173-git (2020-03-26)
Driver version: 4.35.0
Configuration: ./configure

Force systemd to stop lvm2-lvmetad.service before shutting down.

I noticed that systemd sometimes reaches shutdown.target before lvm2-lvmetad.service has been stopped. Since lvm2-lvmetad.service (a.k.a. lvm2_lvmetad_systemd_red_hat.service.in in the "scripts" folder) has

[Unit]
Conflicts=shutdown.target

but no

[Unit]
Before=shutdown.target

in it, this problem can easily occur if the service doesn't react to SIGTERM fast enough.
In case it does happen, with kernels 5.0.0 and up the shutdown/reboot procedure can be interrupted.
If we would add

[Unit]
Before=shutdown.target

to the service file we could avoid the issue. I heared a some Arch Linux users are suffering from this occasional problem, as described in this bug report.
This issue at systemd is also related to the problem, as @patrakov describes.
Thanks for your efforts in advance.

Deadlock when issuing concurrent vgcreate/vgremove

Version information

URL: https://www.sourceware.org/pub/lvm2/LVM2.2.02.183.tgz
sha1sum: c73173d73e2ca17da254883968fbd52a6ce5c2a6

Build steps

export PKG_PATH=/opt/lvm/

./configure --with-confdir=$PKG_PATH/etc --with-default-system-dir=$PKG_PATH/etc/lvm --prefix=$PKG_PATH --sbindir=$PKG_PATH/bin --with-usrsbindir=$PKG_PATH/bin --enable-static_link
make
make install

What were you trying to do?

I remove a volume group using vgremove while creating a different volume group with different PVs using vgcreate.

What happened?

The commands hang both hang. It looks like vgcreate tries to acquire a lock while vgremove holds it.

Steps to reproduce

$ mkdir -p /var/lib/gpaul
$ dd if=/dev/zero of=/var/lib/gpaul/disk1 count=1024 bs=1M
$ dd if=/dev/zero of=/var/lib/gpaul/disk2 count=1024 bs=1M
$ dd if=/dev/zero of=/var/lib/gpaul/disk3 count=1024 bs=1M

$ losetup -f /var/lib/gpaul/disk1
$ losetup -f /var/lib/gpaul/disk2
$ losetup -f /var/lib/gpaul/disk3

$ losetup -a
/dev/loop0: [51713]:41951014 (/var/lib/gpaul/disk1)
/dev/loop1: [51713]:41951015 (/var/lib/gpaul/disk2)
/dev/loop2: [51713]:41951016 (/var/lib/gpaul/disk3)

$ pvcreate /dev/loop0
$ pvcreate /dev/loop1
$ pvcreate /dev/loop2

$ vgcreate gpaul-vg-1 /dev/loop0
$ vgremove --config="log {level=7 verbose=1}" gpaul-vg-1 & vgcreate --config="log {level=7 verbose=1}" gpaul-vg-2 /dev/loop1 /dev/loop2
[1] 22111
    Logging initialised at Thu Aug  8 12:24:47 2019
    Logging initialised at Thu Aug  8 12:24:47 2019
    Archiving volume group "gpaul-vg-1" metadata (seqno 1).
^C  Interrupted...
  Giving up waiting for lock.
  Can't get lock for gpaul-vg-1
  Cannot process volume group gpaul-vg-1
  Interrupted...
  Interrupted...
  Device /dev/loop1 excluded by a filter.
  Device /dev/loop2 excluded by a filter.
    Removing physical volume "/dev/loop0" from volume group "gpaul-vg-1"
  Volume group "gpaul-vg-1" successfully removed
    Reloading config files
$     Reloading config files

[1]+  Done                    vgremove --config="log {level=7 verbose=1}" gpaul-vg-1
$ date
Thu Aug  8 12:25:01 UTC 2019

Note, in the following interleaved logging, process 22112 is vgcreate, process 22111 is vgremove.

I'm attaching the interleaved, verbose, debug logs for the processes as sent to journald.
lvm-deadlock.log

Mounting verity partition results in Can't open blockdev error

Hello together,

when I mount my verity device after creating it using

dmsetup --noudevrules --noudevsync --readonly create vroot 
        --table "0 ${DATA_SECTORS} verity 1 ${root} ${root} 4096 4096 ..."

the mount succeeds but dmesg gives me the error

[    4.754279] 007: /dev/mapper/vroot: Can't open blockdev

The content mounted looks good and everything works and even dmsetup status gives me

....
vroot: 0 203112 verity V

I am a little bit worried about the error message Can't open blockdev even everything is working as expected..

I am currently on v2_02_181 with linux kernel 5.4.77-rt43. I have tried to update to v2_03_10 but the error remains.
Maybe I have to add that before I was using kernel 4.19.148-rt64 and there I didn't had that message.

Any suggestion is welcome.

Thank you and with best regards,
Stefan

LVM hang up always

ensure blk_availability only deactivates devices after local-fs.target

Hi,
in a bug to Ubuntu I got a case reported where the lack of ordering on shutdown causes issues.
I have seen #17 but that only guarantees to have blk_availability complete before reaching shutdown, this is different.

On shutdown due to a lack of Before statements or any other service depending on it via After means that blk_availability will start very early in the shutdown ordering. That can lead to cases (see reported bug) where devices and associated filesystems are gone while still being needed.

If there is any other safeguard that should avoid this, but failing in this case let me know.
Just looking at systemd for shutdown ordering I'd have expected that we'd want to start blkdeactivate only after local-fs.target is reached.

That would mean any services needing local disks/FS are done and that implies we can safely blkdeactivate now.

fail to stop daemon-server

Found a bug in function daemon_start from libdaemon/server/daemon-server.c. It may occur in daemons like lvmetad, lvmlockd, lvmpolld.
In stable-2.02 branch, if we use the daemon lvmetad without -t option. when lvmetad is running a sub process, if the daemon recieve a SIGTERM from systemd. _shutdown_requested will turn to 1, s.threads->next is not NULL, then the while loop could not break, in the next loop, select will be blocked. Sometimes, it will lead to timeout of shutdown machine.
It could be reproduced following the steps:
1.run process 1 like,

while :
do
    lvs
done

2.run process 2 like,

while : 
do 
    service lvm2-lvmetad stop
    if [ $? -ne 0 ];then 
        echo "fail to stop"
        break
    fi
    sleep 2
done

3.soon, process 2 will be blocked, then press "CTRL+C" to stop process 1, we will see process still blocke there. Using gdb attach to lvm2-lvmetad daemon, we will see, lvm2-lvmetad blocket in select function of daemon_start. Although, at this time, _shutdown_requested is 1, s.threads->next is NULL(the _client_thread thread has already quit).

Suggested patch:

diff --git a/libdaemon/server/daemon-server.c b/libdaemon/server/daemon-server.c
index a2216ac..c753473 100644
--- a/libdaemon/server/daemon-server.c
+++ b/libdaemon/server/daemon-server.c
@@ -559,6 +559,8 @@ void daemon_start(daemon_state s)
        thread_state _threads = { .next = NULL };
        unsigned timeout_count = 0;
        fd_set in;
+ struct timeval slect_timeout = { .tv_sec = 1, .tv_usec = 0 };
+        struct timeval *ptimeout;
 
        /*
         * Switch to C locale to avoid reading large locale-archive file used by
@@ -643,9 +645,15 @@ void daemon_start(daemon_state s)
 
        while (!failed) {
                _reset_timeout(s);
+                slect_timeout.tv_sec = 1;
+                slect_timeout.tv_usec = 0;
                FD_ZERO(&in);
                FD_SET(s.socket_fd, &in);
-           if (select(FD_SETSIZE, &in, NULL, NULL, _get_timeout(s)) < 0 && errno != EINTR)
+                ptimeout = _get_timeout(s);
+         if (_shutdown_requested && !ptimeout)
+                 ptimeout = &slect_timeout;
+
+         if (select(FD_SETSIZE, &in, NULL, NULL, ptimeout) < 0 && errno != EINTR)
                        perror("select error");
                if (FD_ISSET(s.socket_fd, &in)) {
                        timeout_count = 0;

LVM volume won't be removed , no process running

I will try to explain the problem as best I can.
I want to delete the volume of a user.
To do this I use a script that takes care of the operation.
Unfortunately, each time the script performs its task, the error reported by lvm is "contains a filesystem in use".
When I run the same script again, this time the lvm is deleted.

My manual tests :

sudo umount /home/whisper40/data/test -> OK
sudo lvremove --yes "/dev/vg_home/test"
  Logical volume vg_home/test contains a filesystem in use.

sudo dmsetup info -c | grep test
-> vg_home-test                 254  10 L--w    1    1      0 LVM-dA5m1HXcQcRHMKuSYfcLtwA0sUUEUN3XmVYkf2wZfBXPKqcexFNGfHAyefTZ2XqH
sudo lsof | grep "254,10" -> No result at all ! so no process

sudo lvremove --yes "/dev/vg_home/test"
  Logical volume vg_home/test contains a filesystem in use.

LVS result : test vg_home Vwi-aotz-- 100.00g pool_0_vg_home 2.34

The umount runs without indicating that a process was using the disk. LVM therefore should not block the deletion because there is no process using the disk.

This problem caused me many trouble on many servers ( Debian 9 and 10 on my side ).
Thanks if you have any idea..

error: unable to create file test/lib/aux.sh: No such file or directory

Hi All,

We try to build OSQuery on MSVC, Lvm2 as a submodule of OSQuery, we encounter the following error when we git clone the source, can you help look at this? Thank you. If I git clone lvm2 separately, "test/lib/aux.sh" also doesn't exist in my local.

Repro step:

open VS x86 tools command
git clone --recursive https://github.com/facebook/osquery F:\gitP\facebook\osquery
cd F:\gitP\facebook\osquery
git submodule sync
git submodule foreach git reset --hard

Error:
F:\gitP\facebook\osquery>git submodule foreach git reset --hard
Entering 'libraries/cmake/source/libarchive/src'
HEAD is now at 98a69539 Libarchive 3.3.2
Entering 'libraries/cmake/source/libaudit/src'
HEAD is now at 20204cc Start 2.4.3 development
Entering 'libraries/cmake/source/libcryptsetup/src'
HEAD is now at 0ba5776 Version 1.7.5.
Entering 'libraries/cmake/source/libdevmapper/src'
error: unable to create file test/lib/aux.sh: No such file or directory
fatal: Could not reset index file to revision 'HEAD'.
Stopping at 'libraries/cmake/source/libdevmapper/src'; script returned non-zero status.

RFE: create multi LVs once time

i want create muti lv once time ,any suggistion?

lvcreate -L 2GB -n lv01 lv02 lv03 vg01

LVM cache cannot be removed if cache volume is lost

If an LVM logical volume is backed by a cached volume, and that cached volume disappears or becomes corrupt, it cannot be removed.

Example, assume a logical volume called lvmgroup/disk:

[root]# modprobe brd rd_nr=2 rd_size=4194304 max_part=1
[root]# pvcreate /dev/ram0
[root]# vgextend lvmgroup /dev/ram0
[root]# lvcreate -l 100%FREE -n cache lvmgroup /dev/ram0
[root]# lvconvert --type cache --cachepool cache --cachemode writeback --cachesettings 'autocommit_time=1000' lvmgroup/disk

After the lvmgroup/disk has been set to cache mode, reboot, or force the ramdisk offline.
Such as:

[root]# lvchange -a n lvmgroup
[root]# rmmod brd
[root]# lvchange -a y lvmgroup

Now try and remove the cache:

[root]# lvconvert --uncache lvmgroup/disk --force
  WARNING: Device for PV rd6lF7-xH6h-Vtes-eMGU-bnTh-60z5-A2ruC3 not found or rejected by a filter.
  Couldn't find device with uuid rd6lF7-xH6h-Vtes-eMGU-bnTh-60z5-A2ruC3.
  WARNING: Cache pool data logical volume lvmgroup/cache_cdata is missing.
  WARNING: Uncaching of partially missing writethrough cache volume lvmgroup/disk might destroy your data.
Do you really want to uncache lvmgroup/disk with missing LVs? [y/n]: y
  device-mapper: reload ioctl on  (250:4) failed: Invalid argument
  **Failed to active cache locally lvmgroup/disk.**

It's possible to force re-add the ram disk using the same uuid and then trying again:

[root]# pvcreate --norestore --uuid=rd6lF7-xH6h-Vtes-eMGU-bnTh-60z5-A2ruC3 /dev/ram0 -ff
Really INITIALIZE physical volume "/dev/ram0" of volume group "lvmgroup" [y/n]? y
  WARNING: Forcing physical volume creation on /dev/ram0 of volume group "lvmgroup"
  Physical volume "/dev/ram0" successfully created.
[root]# lvconvert --uncache lvmgroup/disk --force
  device-mapper: reload ioctl on  (250:3) failed: Invalid argument
  Failed to active cache locally lvmgroup/disk.

At this point, the only way I found this can be fixed is to take the /etc/lvm/backup/lvmgroup file, modify it to remove the cache entries, rename the disk_corig back to disk, add "VISIBLE" flag back, and then run vgcfgrestore -f on the modified file.

udev: disks used as LVM PV no longer show the disk model in ID_MODEL but LVM PV information instead

$ udevadm info /dev/sdX
E: ID_MODEL=LVM PV vBAYkl-gxgV-AZ2n-pgix-pI6y-6cTD-PUxl4C on /dev/sdc
E: ID_MODEL_ENC=WDC\x20WD3000BLFS-01YBU0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20

It was much more helpful to show the actual disk model in ID_MODEL. Also, I'd expect ID_MODEL == trim(decode(ID_MODEL_ENC))

Introduced here: 99bfbbf

Which I guess is somewhat intentional because it explicitly sets ID_MODEL, but the commit mentions "This patch introduces no functional change to the udev rules."

how to enable lvm for this version？？

how to enable lvm for this version？？
LVM version: 2.03.10(2)-git (2020-03-26)
Library version: 1.02.173-git (2020-03-26)
Driver version: 4.35.0
Configuration: ./configure

I can't find lvm2 service on my machine。

libc: FORTIFY: strncpy: detected read past end of 32-byte buffer

I've been compiling lvm2 within the android recovery context, it crashes on many commands (eg vgdisplay) due to the metadata reading past the end of a non-null terminated uuid whilst adding a null terminator to a copy.
It wont actually cause any problems as the next line overwrites the stray random character with a '\0'.

Probably worth fixing upstream too though?

output:
libc: FORTIFY: strncpy: detected read past end of 32-byte buffer

Suggested fix
in:
_check_devs_used_correspond_with_vg
from:
strncpy(vgid, (const char *) vg->id.uuid, sizeof(vgid));
to:
strncpy(vgid, (const char *) vg->id.uuid, ID_LEN);

https://github.com/lvmteam/lvm2/blob/master/lib/metadata/metadata.c#L3448

[metadata] uninitialized members in struct pv_list

Scenario: Given an existed LV lvol0, I want to create another LV on the PVs used by lvol0

I use build_parallel_areas_from_lv() to obtain the pv_list of each segments. However, the returned pv_list is not properly initialized, which causes segfault in subsequent operations.

Here's the patch:

diff --git a/lib/metadata/lv_manip.c b/lib/metadata/lv_manip.c
index 2c569d8f9..27c40d710 100644
--- a/lib/metadata/lv_manip.c
+++ b/lib/metadata/lv_manip.c
@@ -5962,7 +5962,7 @@ static int _add_pvs(struct cmd_context *cmd, struct pv_segment *peg,
        if (find_pv_in_pv_list(&spvs->pvs, peg->pv))
                return 1;
 
-       if (!(pvl = dm_pool_alloc(cmd->mem, sizeof(*pvl)))) {
+       if (!(pvl = dm_pool_zalloc(cmd->mem, sizeof(*pvl)))) {
                log_error("pv_list allocation failed");
                return 0;
        }

pvscan: LVM2-2.02.186 didn't activate some LVs after bootup

I experienced inactive LVs after bootup when using lvm2-2.02.186.

log for lvm2-2.02.185

Aug 31 07:10:01 archlinux systemd[1]: Starting LVM2 PV scan on device 259:5...
Aug 31 07:10:01 archlinux lvm[255]:   Couldn't find device with uuid kerXXT-Qve2-yj88-8Qwj-MpYl-0cdc-VRyzd6.
Aug 31 07:10:01 archlinux lvm[255]:   WARNING: Device for PV kerXXT-Qve2-yj88-8Qwj-MpYl-0cdc-VRyzd6 not found or rejected by a filter.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/debian-root. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/linux-home. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/archlinux-var. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/debian-root. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/linux-home. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/archlinux-var. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/debian-root. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/linux-home. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/archlinux-var. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/debian-root. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/linux-home. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/archlinux-var. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/debian-root. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/linux-home. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing refresh of partial LV vg0/archlinux-var. Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   vg0: refresh before autoactivation failed.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing activation of partial LV vg0/debian-root.  Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing activation of partial LV vg0/linux-home.  Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   Refusing activation of partial LV vg0/archlinux-var.  Use '--activationmode partial' to override.
Aug 31 07:10:01 archlinux lvm[255]:   1 logical volume(s) in volume group "vg0" now active
Aug 31 07:10:01 archlinux lvm[255]:   vg0: autoactivation failed.
Aug 31 07:10:01 archlinux systemd[1]: lvm2-pvscan@259:5.service: Main process exited, code=exited, status=5/NOTINSTALLED
Aug 31 07:10:01 archlinux systemd[1]: lvm2-pvscan@259:5.service: Failed with result 'exit-code'.
Aug 31 07:10:01 archlinux systemd[1]: Failed to start LVM2 PV scan on device 259:5.
Aug 31 07:10:01 archlinux systemd[1]: lvm2-pvscan@259:5.service: Consumed 16ms CPU time.
Aug 31 07:10:03 hpArch systemd[1]: Starting LVM2 PV scan on device 259:5...
Aug 31 07:10:03 hpArch lvm[386]:   WARNING: lvmetad is being updated, retrying (setup) for 10 more seconds.
Aug 31 07:10:06 hpArch lvm[386]:   4 logical volume(s) in volume group "vg0" now active
Aug 31 07:10:06 hpArch systemd[1]: Started LVM2 PV scan on device 259:5.
Aug 31 07:12:42 hpArch systemd[1]: Stopping LVM2 PV scan on device 259:5...
Aug 31 07:12:42 hpArch systemd[1]: lvm2-pvscan@259:5.service: Succeeded.
Aug 31 07:12:42 hpArch systemd[1]: Stopped LVM2 PV scan on device 259:5.
Aug 31 07:12:42 hpArch systemd[1]: lvm2-pvscan@259:5.service: Consumed 19ms CPU time.
-- Reboot --

log for lvm2-2.02.186

Aug 31 07:13:04 archlinux systemd[1]: Starting LVM2 PV scan on device 259:5...
Aug 31 07:13:04 archlinux lvm[233]:   Couldn't find device with uuid kerXXT-Qve2-yj88-8Qwj-MpYl-0cdc-VRyzd6.
Aug 31 07:13:04 archlinux lvm[233]:   pvscan[233] activating all directly (lvmetad token) 259:5
Aug 31 07:13:04 archlinux lvm[233]:   WARNING: Device for PV kerXXT-Qve2-yj88-8Qwj-MpYl-0cdc-VRyzd6 not found or rejected by a filter.
Aug 31 07:13:04 archlinux lvm[233]:   pvscan[233] VG vg0 run autoactivation.
Aug 31 07:13:04 archlinux lvm[233]:   Refusing activation of partial LV vg0/debian-root.  Use '--activationmode partial' to override.
Aug 31 07:13:04 archlinux lvm[233]:   Refusing activation of partial LV vg0/linux-home.  Use '--activationmode partial' to override.
Aug 31 07:13:04 archlinux lvm[233]:   Refusing activation of partial LV vg0/archlinux-var.  Use '--activationmode partial' to override.
Aug 31 07:13:04 archlinux lvm[233]:   1 logical volume(s) in volume group "vg0" now active
Aug 31 07:13:04 archlinux lvm[233]:   vg0: autoactivation failed.
Aug 31 07:13:04 archlinux systemd[1]: lvm2-pvscan@259:5.service: Main process exited, code=exited, status=5/NOTINSTALLED
Aug 31 07:13:04 archlinux systemd[1]: lvm2-pvscan@259:5.service: Failed with result 'exit-code'.
Aug 31 07:13:04 archlinux systemd[1]: Failed to start LVM2 PV scan on device 259:5.
Aug 31 07:13:04 archlinux systemd[1]: lvm2-pvscan@259:5.service: Consumed 13ms CPU time.
Aug 31 07:13:05 hpArch systemd[1]: Starting LVM2 PV scan on device 259:5...
Aug 31 07:13:07 hpArch lvm[362]:   pvscan[362] VG vg0 skip autoactivation.
Aug 31 07:13:07 hpArch systemd[1]: Started LVM2 PV scan on device 259:5.

It seems to be caused by 8bcd482.

I guess that avoiding redundant activation accidently leads to skipping autoactivation after initramfs was load, which cause some of LVs be inactive. Though I currently don't know why not all of my LVs can be activated at once.

Some extra infomation was given in https://bbs.archlinux.org/viewtopic.php?id=248788

what is the benefit for using aio in bcache?

In my environment

when I use aio engine created by create_async_io_engine()

time lvs

real 0m0.093s
user 0m0.017s
sys 0m0.009s

when I close aio engine by setting use_aio=0 in /etc/lvm/lvm.conf

time lvs

real 0m0.026s
user 0m0.007s
sys 0m0.019s

I wonder why adding aio feature to lvm? It takes much time when call io_setup io_destroy. Actually， it doesn't make scanning faster.
Thanks

lvremove pitfall/user experience

This may not be a common experience, but I want to share it, along with a couple of simple solutions to make it a little better, and less terrifying to use lvremove.

I rarely have to remove a logical volume, but every time it happens I know I'm going to fall into this trap. First of all, I never remember the arguments, so I check lvremove -h. The output of that gives an arbitrary VG|LV|Tag|Select ... as the first argument, with no clarification as to what the format of any of these are. There is --longhelp, but it redirects you to a manpage. So invariably I try to run this command (an argument syntax that matches lvcreate):

lvremove my_vg my_lv

This command is absolutely terrifying to run the first time because it will start telling you every lv it cannot delete because they are in use. On top of that, SIGINT is being trapped, so you cannot use CTRL-C to abort this operation. Run this on a system with dozens of LVs, and you're stuck opening another terminal to send a SIGKILL to get control back.

My request here is for two changes:

Do not trap SIGINT until the code actually needs to be uninterruptable
Add the most common use case(s) of lvremove as an example to the end of the lvremove --help output

These two changes are minor, will take years to reach the environment I work in, but they could make another user's life a little more pleasant.

undefined reference to `dm_udev_create_cookie'

When compiling the latest release of ...178, I
get:

dmsetup.o: In function _udevcreatecookie': dmsetup.c:(.text+0x574b): undefined reference to dm_udev_create_cookie'
collect2: error: ld returned 1 exit status

Deprecate: 'mirrored' log option for the 'mirror' segment type

Mirrored log with 'mirror' segtype should never be used. Instead, people should be using the 'raid1' segtype, which has been the default mirror segtype since "Version 2.02.100 - 13th August 2013". It has also been the default mirror segtype since RHEL 7.0.

Downsides to using mirrored log mirrors are:

requires 4 devices for 2-way mirror - increasing fault exposure
cannot be used in a cluster (so no-one uses it there anyway)
if logs are on same devs as images, the log is removed anyway when a image dies unless it is 3-way or greater
there are known issues with the mirror segtype and snapshots - mirrored log makes this worse by creating a stack of mirror types

Steps of mirrored log mirror (MLM) deprecation:

Warn users when creating MLM that it is being deprecated and advise alternative.
Date/Release: ? (now?)
Disable MLM creation
Date/Release: ?
Warn users when activating MLM that it is being deprecated and advise alternative.
Date/Release: ? (same time as #2)
Disable MLM activation (user is unable to create or activate MLM)
Note: Users will still be able to convert their logs to non-mirrored.
Date/Release: ?

See also: RHBZ: https://bugzilla.redhat.com/1497345

lvm2 scan and monitor services slow down boot in kernel 5.0.0

After recently upgrading kernel to version 5.0.0, boot time has been terribly slow because of lvm2 scan and/or monitor services.

➜ % ~  uname -r
5.0.0-arch1-1-ARCH
➜ % ~  pacman -Qi lvm2
Name: lvm2
Version: 2.02.183-2
➜ % ~  systemd-analyze blame 
         23.841s lvm2-monitor.service
         23.509s lvm2-pvscan@8:17.service
         23.412s lvm2-pvscan@254:1.service
         23.173s lvm2-pvscan@254:3.service

And the problem could be related to lvmetad cache...

➜ % ~  journalctl -b 0 | grep lvmetad
mar 06 14:40:08 lvm[369]:   WARNING: lvmetad is being updated by another command (pid 472).
mar 06 14:40:08 lvm[369]:   WARNING: Not using lvmetad because cache update failed.

Here you can check a boot log.

lvm2 writeback cache flush loops forever

lvmcache in writeback mode does not ever complete flush sometimes.
Can I please get some clarity on what exactly is the rootcause and when this was resolved?

Even putting the lvmcache into cleaner policy did not make any difference.
There is no kernel crash/traceback seen.

root@pdc4-sm35:~# lvs -o cache_dirty_blocks,cache_policy pwx0/pool
  CacheDirtyBlocks Cache Policy
               367 cleaner
root@pdc4-sm35:~#

root@pdc4-sm35:~# lvconvert --splitcache pwx0/pool
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
  367 blocks must still be flushed.
^C
root@pdc4-sm35:~#

root@pdc4-sm35:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial
root@pdc4-sm35:~# lvm version
  LVM version:     2.02.133(2) (2015-10-30)
  Library version: 1.02.110 (2015-10-30)
  Driver version:  4.34.0
root@pdc4-sm35:~# uname -r
4.4.0-21-generic
root@pdc4-sm35:~#

`lvconvert --cachedevice` doesn't support `--chunksize`

Background

Running on Debian Bullseye.

% sudo lvm version
  LVM version:     2.03.10(2) (2020-08-09)
  Library version: 1.02.173 (2020-08-09)
  Driver version:  4.39.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-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --libdir=/lib/x86_64-linux-gnu --sbindir=/sbin --with-usrlibdir=/usr/lib/x86_64-linux-gnu --with-optimisation=-O2 --with-cache=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 --with-udev-prefix=/ --enable-applib --enable-blkid_wiping --enable-cmdlib --enable-dmeventd --enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-lvmpolld --enable-notify-dbus --enable-pkgconfig --enable-readline --enable-udev_rules --enable-udev_sync

Problem

When using lvconvert with --cachedevice with a large cache drive (~2TB), lvconvert will throw an error saying there are too many chunks and recommends using --chunksize to reduce the number.

% sudo lvconvert --type cache --cachedevice /dev/sdb vg/lv
Use all 1.63 TiB from /dev/sdb for cache? [y/n]: y
  Creating cachevol LV lv with size 1.63 TiB.
  Logical volume "lv_cache" created.
  Cache data blocks 3506397184 and chunk size 128 exceed max chunks 1000000.
  Use smaller cache, larger --chunksize or increase max chunks setting.

However, if you try to pass --chunksize to lvconvert it refuses to use it, making it impossible to proceed without increasing max chunks (which isn't desirable in this case).

% sudo lvconvert --type cache --chunksize 2M --cachedevice /dev/sdb vg/lv
  Command does not accept option: --chunksize 2M.

Ideally, lvconvert should support --chunksize when combined with --cachedevice, or support automatic sizing like when using --cachepool

Unfortunately using --cachepool doesn't produce the same results as --cachepool expects free extents, which don't exist, as all of them have been allocated to either the origin LV or the cache.

% sudo lvconvert --type cache --cachepool lv_cache vg/lv
  Using 2.00 MiB chunk size instead of default 64.00 KiB, so cache pool has less than 1000000 chunks.
  WARNING: Converting vg/lv_cache to cache pool's data volume with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert vg/lv_cache? [y/n]: y
  Volume group "vg" has insufficient free space (0 extents): 10 required.
  LV vg/lv_cache could not be converted to a cache pool.

Possible off-by-one error in %VG notation in lvmtools

I spotted a curious behavior when using lvcreate/lvextend:

root@thinkpad:~# dpkg -l | grep 'lvm2 '
ii  lvm2                                  2.02.176-4.1ubuntu3                 amd64        Linux Logical Volume Manager
root@thinkpad:~# lvextend /dev/xubuntu-vg/lvol0 -l 1%VG ^C
root@thinkpad:~# dpkg -l | grep 'lvm2 '
ii  lvm2                                  2.02.176-4.1ubuntu3                 amd64        Linux Logical Volume Manager
root@thinkpad:~# lvcreate /dev/xubuntu-vg -l 1%VG 
  Logical volume "lvol0" created.
root@thinkpad:~# lvextend /dev/xubuntu-vg/lvol0 -l 1%VG 
  Size of logical volume xubuntu-vg/lvol0 changed from 2,23 GiB (571 extents) to 2,23 GiB (572 extents).
  Logical volume xubuntu-vg/lvol0 successfully resized.

To me it seems that it should be calculated to the same absolute number of extents in both tools

In my limited testing it was always extended by one extent, no matter which size i used

LVM2.2.02.179/lib/metadata/metadata.c: confused logic ?

LVM2.2.02.179/lib/metadata/metadata.c:4125] -> [LVM2.2.02.179/lib/metadata/metadata.c:4179]: (warning) Identical inner 'if' condition is always true.

Line 4125 is

 if (!correct_vg) {

and line 4179 is

             if (!correct_vg) {
                            correct_vg = vg;
                            if (!_update_pv_list(cmd->mem, &all_pvs, correct_vg)) {
                                    _free_pv_list(&all_pvs);
                                    fid->ref_count--;
                                    release_vg(vg);
                                    return_NULL;
                            }
                            continue;
                    }

which means that the continue always executes and so the rest of the code
in the block can never execute. Looks suspicious to me.

segmentation faults with uClibc-ng

When using a system with uClibc-ng for embedded targets with Buildroot or
Gentoo/hardened on Desktop there is a segmentation fault trying to use cryptsetup.
The reason for it is, that uClibc-ng does not support symbol versioning.

See here a workaround:
https://bugs.busybox.net/attachment.cgi?id=7496&action=diff&collapsed=&headers=1&format=raw

Is the combat code still required in libdm/ioctl/libdm-iface.c?

Thanks

filter out zero-sized devices by looking at "size" attribute in sysfs to avoid "no medium found" errors

Not sure if this is an issue or an expected behaviour, so let's ask.

➜ # ~  pvscan --cache
  /dev/sdd: open failed
  /dev/sde: open failed
  /dev/sdf: open failed
  /dev/sdg: open failed
➜ # ~  pvscan
  /dev/sdd: open failed
  /dev/sde: open failed
  /dev/sdf: open failed
  /dev/sdg: open failed
  PV /dev/mapper/ssd         VG ssd             lvm2 [<118,74 GiB / <108,74 GiB free]
  PV /dev/sdb1               VG storage         lvm2 [<931,51 GiB / 0    free]
  PV /dev/mapper/crypt_hdd   VG hdd             lvm2 [<465,76 GiB / <73,76 GiB free]
  Total: 3 [1,48 TiB] / in use: 3 [1,48 TiB] / in no VG: 0 [0   ]

If I run pvscan without --cache and use_lvmetad option is enabled in configuration, I'd expect second command from the example to not scan devices again, which looks like it's happening.

Also, but not strictly related, is it normal that [email protected] unit in systemd runs without cache at boot? For some reason I started to see ... open failed messages during boot process.

This is for lvm2 2.02.183 version on Arch Linux.

Thanks!

Not support Ubuntu?

As the dbus message with prefix com.redhat.lvmdbus1, does it mean only support Redhat platform? I just did a quick testing on Ubuntu 14.04.5, always got nothing when query managed objects. Did I miss anything?

various string-handling issues in pvscan

Probably not hugely important except the more I look at this the more afraid of it I am. Casual inspection makes it look like it's hard to trigger anything obviously bad, because there's usually other guards around things, but the whole thing feels like it's halfway through a refactor.

#define NAME_LEN 128

static void _online_pvid_file_remove_devno(int major, int minor)
{
	char path[PATH_MAX];
	char file_vgname[NAME_LEN];```

But wait, what about online_pvid_file_read, which is used to populate this?

/* vgname points to an offset in buf */
if ((name = _vgname_in_pvid_file_buf(buf)))
	strncpy(vgname, name, NAME_LEN);
else
	log_debug("No vgname in %s", path);

return 1;```

If there's no vgname in the path, we return 1, indicating success, after having not touched vgname here. It appears that nearby callers are passing in zeroed buffers, but that may not always be true. On the other hand, we're still returning 1 rather than 0 in what appears to be an error case, so in that case we'd be handing back an empty vgname buffer even though the function returned 1; maybe this is why everything ignores the return code and instead checks vgname[0].

More concerningly, though: strncpy only nul-terminates strings if there's enough space. If the maximum allowed name length is 128 characters, and you use all 128, you don't get a nul. Furthermore, you could use more than 128; it won't run PAST the buffer, but it'll fill the buffer and not terminate it.

I have no idea whether this is exploitable or anything, I just noticed it because someone mentioned an unrelated question about the code and I happened to see a strncpy and got nervous.

I'm also definitely nervous about dm_snprintf, which is restoring the semantics snprintf had in glibc prior to 1999, which seems like long enough ago that I'm a little distrustful of it.

Build fails with --enable-static_link

Build with --enable-static_link fails due to undefined references:

$ ./configure --enable-static_link
[...]
$ make
[...]
    [CC] dmsetup.static
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__register_frame_info_bases.part.0':
(.text+0x1678): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__register_frame_info_table_bases':
(.text+0x1778): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__deregister_frame_info_bases':
(.text+0x182e): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: (.text+0x187a): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: (.text+0x18fd): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE':
(.text+0x1a2c): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: (.text+0x1b58): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: (.text+0x1b99): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__register_frame_info_bases.part.0':
(.text+0x16ab): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__register_frame_info_table_bases':
(.text+0x17ab): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../libdm/ioctl/libdevmapper.a(libdm-stats.o): in function `_build_histogram_arg':
libdm-stats.c:(.text+0x3a0): undefined reference to `log10'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: libdm-stats.c:(.text+0x3a5): undefined reference to `lround'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../libdm/ioctl/libdevmapper.a(libdm-stats.o): in function `_stats_group_tag_len.isra.0':
libdm-stats.c:(.text+0x201c): undefined reference to `log10'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: libdm-stats.c:(.text+0x206a): undefined reference to `log10'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../libdm/ioctl/libdevmapper.a(libdm-string.o): in function `dm_size_to_string':
libdm-string.c:(.text+0x1174): undefined reference to `nearbyint'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../libdm/ioctl/libdevmapper.a(pool.o): in function `dm_pool_create':
pool.c:(.text+0xf5): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: pool.c:(.text+0x110): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../libdm/ioctl/libdevmapper.a(pool.o): in function `dm_pool_destroy':
pool.c:(.text+0x189): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: pool.c:(.text+0x19d): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../../libdm/ioctl/libdevmapper.a(pool.o): in function `dm_pools_check_leaks':
pool.c:(.text+0x5f2): undefined reference to `pthread_mutex_lock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: pool.c:(.text+0x68a): undefined reference to `pthread_mutex_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: pool.c:(.text+0x6d2): undefined reference to `pthread_mutex_unlock'
collect2: error: ld returned 1 exit status

There is a related bug tracked at Gentoo: https://bugs.gentoo.org/762017

After a quick look it seems that the lvm.static target, for instance, misses -lrt and -lcap, but I have not investigated further.

git clone problems

When I tried to clone the code from this reporitory with windows 10 and gitbash(2.32.0) , i get a error like this:
Cloning into 'lvm2'...
warning: ----------------- SECURITY WARNING ----------------
warning: | TLS certificate verification has been disabled! |
warning: ---------------------------------------------------
warning: HTTPS connections may not be secure. See https://aka.ms/gcmcore-tlsverify for more information.
remote: Enumerating objects: 135637, done.
remote: Counting objects: 100% (4613/4613), done.
remote: Compressing objects: 100% (1661/1661), done.
remote: Total 135637 (delta 3292), reused 3861 (delta 2914), pack-reused 131024
Receiving objects: 100% (135637/135637), 37.34 MiB | 2.39 MiB/s, done.
Resolving deltas: 100% (104906/104906), done.
error: invalid path 'test/lib/aux.sh'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
I finally find that the aux.sh file name cause this proble. Then I create a issue on git, but they say it is filename proble(anyway, i don't think so). So if any probility to change the file name?

Scrubbing not possible on RAID5 with 3 LUKS SSDs

Description of problem:
I can't scrub (check / repair) the raid.

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

How reproducible:
Every time.

Steps to Reproduce:

Create a LUKS fulldisk partition on each of the 3 SSDs
Use LVM to create a RAID 5
Format the new RAID5 partition with BTRFS
Execute sudo lvchange --syncaction check cryptdata_raid5/home

Actual results:
Command on LV cryptdata_raid5/home does not accept LV type linear.
Command not permitted on LV cryptdata_raid5/home.

Expected results:
Checking and repairing.

Additional info:
Do I need to use MDADM to make a RAID5 first and use the MDADM tools for scrubbing?
The arch wiki said it's perfectly fine to create a RAID5 via LVM directly.

lvmcache (write-through) massive corruption - post-mortem question(s)

Hi,

I originally tried to send this question via mailing list, but it always fails with

host us-smtp-inbound-1.mimecast.com [207.211.30.237]
    SMTP error from remote mail server after RCPT TO:<[email protected]>:
    550 Invalid Recipient -

So, hope it's fine to ask here.

I had very unusual issues with 2 cache pools I've been using on one of my machines.

First the setup. The lvs dump below is the one from ca. 5-6 months ago, a bit after we created the setup.

xs22:~☠ lvs -a -o+seg_le_ranges
  LV                      VG    Attr       LSize   Pool   Origin               Data%  Meta%  Move Log Cpy%Sync Convert LE Ranges                                                
  [cp0]                   x22v0 Cwi---C--- 200.04g                             50.41  0.80            0.00             [cp0_cdata]:0-1706                                       
  [cp0_cdata]             x22v0 Cwi-ao---- 200.04g                                                                     /dev/sdt2:35-1741                                        
  [cp0_cmeta]             x22v0 ewi-aor--- 600.00m                                                    100.00           [cp0_cmeta_rimage_0]:0-4,[cp0_cmeta_rimage_1]:0-4        
  [cp0_cmeta_rimage_0]    x22v0 iwi-aor--- 600.00m                                                                     /dev/sdu3:1-5                                            
  [cp0_cmeta_rimage_1]    x22v0 iwi-aor--- 600.00m                                                                     /dev/sdc3:1-5                                            
  [cp0_cmeta_rmeta_0]     x22v0 ewi-aor--- 120.00m                                                                     /dev/sdu3:0-0                                            
  [cp0_cmeta_rmeta_1]     x22v0 ewi-aor--- 120.00m                                                                     /dev/sdc3:0-0                                            
  [cp1]                   x22v0 Cwi---C---  92.11g                             55.54  1.24            0.00             [cp1_cdata]:0-785                                        
  [cp1_cdata]             x22v0 Cwi-ao----  92.11g                                                                     /dev/sdt2:1742-2527                                      
  [cp1_cmeta]             x22v0 ewi-aor--- 120.00m                                                    100.00           [cp1_cmeta_rimage_0]:0-0,[cp1_cmeta_rimage_1]:0-0        
  [cp1_cmeta_rimage_0]    x22v0 iwi-aor--- 120.00m                                                                     /dev/sdu3:7-7                                            
  [cp1_cmeta_rimage_1]    x22v0 iwi-aor--- 120.00m                                                                     /dev/sdc3:7-7                                            
  [cp1_cmeta_rmeta_0]     x22v0 ewi-aor--- 120.00m                                                                     /dev/sdu3:6-6                                            
  [cp1_cmeta_rmeta_1]     x22v0 ewi-aor--- 120.00m                                                                     /dev/sdc3:6-6                                            
  gerrit-new              x22v0 Vwi-aot--- 128.09g tp_ssd                      1.54                                                                                             
  gerrit-new-backup       x22v0 Vwi-aot--- 128.09g tp_big                      0.88                                                                                             
  gitlab_reg              x22v0 Vwi-aot---   1.00t tp_big                      28.68                                                                                            
  gitlab_root             x22v0 Vwi-aot--- 300.00g tp_ssd                      75.81                                                                                            
  local-ranch-mach1       x22v0 Vwi-aot---  32.11g tp_big                      21.00                                                                                            
  local-ranch-mach2       x22v0 Vwi-aot--- 128.09g tp_big                      19.14                                                                                            
  local-ranch-mach3       x22v0 Vwi-a-t--- 128.09g tp_big                      0.00                                                                                             
  local-ranch-mach4       x22v0 Vwi-a-t--- 128.09g tp_big                      0.00                                                                                             
  [lvol0_pmspare]         x22v0 ewi-------   4.10g                                                                     /dev/sdt2:0-34                                           
  nussknacker1            x22v0 Vwi-aot--- 128.09g tp_big                      11.69                                                                                            
  nussknacker2            x22v0 Vwi-aot--- 128.09g tp_big                      11.18                                                                                            
  openvpn-new             x22v0 Vwi-aot---  64.10g tp_big                      6.50                                                                                             
  touk-elk4               x22v0 Cwi-aoC--- 300.00g [cp1]  [touk-elk4_corig]    55.54  1.24            0.00             [touk-elk4_corig]:0-2559                                 
  [touk-elk4_corig]       x22v0 owi-aoC--- 300.00g                                                                     /dev/md125:17477-20036                                   
  tp_big                  x22v0 twi-aot---   2.00t                             17.56  0.57                             [tp_big_tdata]:0-17476                                   
  [tp_big_tdata]          x22v0 Cwi-aoC---   2.00t [cp0]  [tp_big_tdata_corig] 50.41  0.80            0.00             [tp_big_tdata_corig]:0-17476                             
  [tp_big_tdata_corig]    x22v0 owi-aoC---   2.00t                                                                     /dev/md125:0-17476                                       
  [tp_big_tmeta]          x22v0 ewi-aor---   4.10g                                                    100.00           [tp_big_tmeta_rimage_0]:0-34,[tp_big_tmeta_rimage_1]:0-34
  [tp_big_tmeta_rimage_0] x22v0 iwi-aor---   4.10g                                                                     /dev/sdu3:30-64                                          
  [tp_big_tmeta_rimage_1] x22v0 iwi-aor---   4.10g                                                                     /dev/sdc3:30-64                                          
  [tp_big_tmeta_rmeta_0]  x22v0 ewi-aor--- 120.00m                                                                     /dev/sdu3:29-29                                          
  [tp_big_tmeta_rmeta_1]  x22v0 ewi-aor--- 120.00m                                                                     /dev/sdc3:29-29                                          
  tp_ssd                  x22v0 twi-aot---   1.00t                             22.40  0.94                             [tp_ssd_tdata]:0-8738                                    
  [tp_ssd_tdata]          x22v0 Twi-ao----   1.00t                                                                     /dev/md126:0-8738                                        
  [tp_ssd_tmeta]          x22v0 ewi-aor---   2.11g                                                    100.00           [tp_ssd_tmeta_rimage_0]:0-17,[tp_ssd_tmeta_rimage_1]:0-17
  [tp_ssd_tmeta_rimage_0] x22v0 iwi-aor---   2.11g                                                                     /dev/sdu3:11-28                                          
  [tp_ssd_tmeta_rimage_1] x22v0 iwi-aor---   2.11g                                                                     /dev/sdc3:11-28                                          
  [tp_ssd_tmeta_rmeta_0]  x22v0 ewi-aor--- 120.00m                                                                     /dev/sdu3:10-10                                          
  [tp_ssd_tmeta_rmeta_1]  x22v0 ewi-aor--- 120.00m                                                                     /dev/sdc3:10-10

  PV         VG    Fmt  Attr PSize   PFree   1st PE  Ext    
  /dev/md125 x22v0 lvm2 a--   10.91t   8.52t  30.00m 120.00m
  /dev/md126 x22v0 lvm2 a--    4.91t   3.91t  30.00m 120.00m
  /dev/sdc3  x22v0 lvm2 a--   33.16g  26.72g   1.00m 120.00m
  /dev/sdt2  x22v0 lvm2 a--  697.85g 693.75g   1.00m 120.00m
  /dev/sdu3  x22v0 lvm2 a--   33.16g  26.72g   1.00m 120.00m

sdc3 and sdu3 are 2 metadata ssds - used for cache pools' meta as well as thin volumes' meta.
tp_big is using md125 (for data) and sdc3/u3 for metadata (--type raid1 -m 1)
both thin pools' chunk size matches underlying raid's stripe width
cp0 is using sdt2 (for data) and sdc3/u3 for metadata (--type raid1 -m 1)
cp1 - as cp0, aside being smaller
the unusual extent side is due to:
- raid chunk and multiplier chosen to remain aligned if we decided to reshape at some point in the future
- more coarse granularity (we don't really need default 4mb)
cache chunk (cp0, cp1) was 512kb (matching underlying raid's chunk size)
both cp0 and cp1 WERE created as write-through caches (the relevant options were never used/altered, nor the related lvm.conf options were changed)
lvm.conf changes: pass discards down, "performance" when deciding on chunk size, raided metadata forced to be on separate physical volumes
md125 is a basic mdraid r5 (3 data, 1 parity) with write-back journal on 2 ssds in raid1 mode
md126 is a basic mdraid r5 with internal bitmap

The current state (post-mortem - with cp0 and cp1 gone, and anything that was using tp_big (with its data cached by cp0) - either removed or recreated from backups/ansible/puppet/etc.

xs22:/home/msl☠ lvs -a -o +chunk_size,seg_le_ranges
  LV                      VG    Attr       LSize    Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert Chunk LE Ranges                                                
  gerrit-backup           x22v0 Vwi-aot--- <128.09g tp_big        45.50                                      0                                                           
  gerrit-new              x22v0 Vwi-aot--- <128.09g tp_ssd        41.50                                      0                                                           
  gerrit-new-backup       x22v0 Vwi-aot--- <128.09g tp_big        2.44                                       0                                                           
  gerrit-root             x22v0 Vwi-aot--- <128.09g tp_ssd        28.24                                      0                                                           
  gitlab_reg              x22v0 Vwi-aot---    1.00t tp_big        26.40                                      0                                                           
  gitlab_root             x22v0 Vwi-aot---  300.00g tp_ssd        88.89                                      0                                                           
  [lvol0_pmspare]         x22v0 ewi-------    4.10g                                                          0  /dev/sdt2:0-34                                           
  nusknacker-staging      x22v0 Vwi-aot--- <128.09g tp_big        10.79                                      0                                                           
  nussknacker1            x22v0 Vwi-aot--- <128.09g tp_big        10.17                                      0                                                           
  nussknacker2            x22v0 Vwi-aot--- <128.09g tp_big        8.29                                       0                                                           
  openvpn-new             x22v0 Vwi-aot---   64.10g tp_big        8.38                                       0                                                           
  touk-elk4               x22v0 -wi-ao---- <400.08g                                                          0  /dev/md125:17477-20890                                   
  tp_big                  x22v0 twi-aot---    2.00t               18.29  0.58                             1.50m [tp_big_tdata]:0-17476                                   
  [tp_big_tdata]          x22v0 Twi-ao----    2.00t                                                          0  /dev/md125:0-17476                                       
  [tp_big_tmeta]          x22v0 ewi-aor---    4.10g                                      100.00              0  [tp_big_tmeta_rimage_0]:0-34,[tp_big_tmeta_rimage_1]:0-34
  [tp_big_tmeta_rimage_0] x22v0 iwi-aor---    4.10g                                                          0  /dev/sdu3:30-64                                          
  [tp_big_tmeta_rimage_1] x22v0 iwi-aor---    4.10g                                                          0  /dev/sdc3:30-64                                          
  [tp_big_tmeta_rmeta_0]  x22v0 ewi-aor---  120.00m                                                          0  /dev/sdu3:29-29                                          
  [tp_big_tmeta_rmeta_1]  x22v0 ewi-aor---  120.00m                                                          0  /dev/sdc3:29-29                                          
  tp_ssd                  x22v0 twi-aot---    1.00t               34.76  1.03                             1.50m [tp_ssd_tdata]:0-8738                                    
  [tp_ssd_tdata]          x22v0 Twi-ao----    1.00t                                                          0  /dev/md126:0-8738                                        
  [tp_ssd_tmeta]          x22v0 ewi-aor---   <2.11g                                      100.00              0  [tp_ssd_tmeta_rimage_0]:0-17,[tp_ssd_tmeta_rimage_1]:0-17
  [tp_ssd_tmeta_rimage_0] x22v0 iwi-aor---   <2.11g                                                          0  /dev/sdu3:11-28                                          
  [tp_ssd_tmeta_rimage_1] x22v0 iwi-aor---   <2.11g                                                          0  /dev/sdc3:11-28                                          
  [tp_ssd_tmeta_rmeta_0]  x22v0 ewi-aor---  120.00m                                                          0  /dev/sdu3:10-10                                          
  [tp_ssd_tmeta_rmeta_1]  x22v0 ewi-aor---  120.00m                                                          0  /dev/sdc3:10-10

The setup with cache pools was working fine - with virtual machine images created on top of tp_big, tp_ssd or directly on top of "fast" (/dev/md126) or "slow" (/dev/md125) volumes.

At one point the machine had hard power reset (we were moving it to different outlets and redundant psu didn't work as it should have ...) - but everything worked fine afterwards - I'm mentioning it as perhaps it was relevant to the case (this was around 3-4 months ago).

Then at some point we decided to do some cp1 adjustments. And this is when the problems started.

A simple: lvconvert --splitcache x22v0/touk-elk4 .......

... greeted me with rather unexpected: "Flushing nnn blocks for cache VG/LV" - what's worse it was stuck in an endless loop, with unchanging 'nnn' value.

why would a write-through cache want to flush anything ?
why was it stuck ? (I did search for similar issues - and found mentions of that happening, but all were related to w-b cache pools)
were there any bugs that could cause such thing happening ? (such as - unability to write to its origin during normal operation, or confusing the cache about being write-back, or anything else)
if not bugs, then perhaps creating metadata on raid1 caused the cache pool to default to w-b mode ?
could the hard reset some time prior (as mentioned above) - be the culprit ?

Now with this particular volume (touk-elk4) the things ended "ok" - as simple lvchange -an followed by lvchange -ay managed to "unstuck" subsequent lvconvert --splitcache - so it finished successfully. It did take a while, but the vm with its filesystem was clean.

Some days ago we wanted to remove cp0: lvconvert --splitcache 'x22v0/[tp_big_tdata]'

The exact thing happened as earlier with cp1 (attempt to flush + endless flushing loop on a formally w-t cache) - unfortunately in this case after we did:

vgchange -an
vgchange -ay

The cp0 cache was already detached from its origin (why ?). My mistake perhaps that - after that - I didn't forcibly recreate cached volume without clearing metadata (but frankly I didn't expect problems seeing cp0 detached). After lvremove x22v0/cp0 - anything that existed on volumes created on top of tp_big was heavily corrupted.

So essentially - the same questions as with cp1 case above, plus:

why was cp0 detached out of the blue ? The pre-vgchange --splitcache never finished its job (stuck in flushing loop)
while it worked fine for us - is chaching thin pool's data a formally supported configuration ?

That particular machine was running under debian stretch (lvm: 2.02.168-2) and with 5.0.20 kernel (we had to apply https://patchwork.kernel.org/patch/10837777/ before it landed in official kernels).

Anyway, I'd rather avoid such surprises in the future (should we decide to use lvmcache again). Any comments or explanations on what did/could have happen/ed - would be appreciated.

udev/69-dm-lvm-metad.rules.in shouldn't invoke systemd-run from BINDIR

https://github.com/lvmteam/lvm2/blob/master/udev/69-dm-lvm-metad.rules.in#L111 calls systemd-run from (BINDIR), which is not necessarily where the systemd binaries are installed.

This should probably be discovered from $PATH and made overridable, like THIN_*_CMD and others.

Reading 2c42f60, it seems it's necessary to invoke systemd-run here, and it's not possible to model this differently.

Unconditional libaio.h dependency (unused for device-mapper)

./configure depends unconditionally on libaio.h, even if only make device-mapper and make install_device-mapper shall be finally run/used. A more friendly solution rather sed -e 's/libaio.h//' -i configure for ./configure would be appreciated.

RAID5 segment fault when extended

I get an segmentfault when trying to use lvextend. I know this is proabebly not what anyone would do, but a segmentfault is always bad.
The same thing works out with a striped LV adding a linear blok with lvextend -i1

Using loop device I tried out:

  vgcreate vgtest /dev/loop1 /dev/loop2 /dev/loop3
  lvcreate --type raid5 -l100%FREE -n lvtest vgtest
  vgextend vgtest /dev/loop4

All good

Now:

  lvextend -i1 -l+100%FREE vgtest/lvtest
  Segment fault (throws kernel)

Bad

dmesg
[40709.266188] traps: lvextend[45557] general protection fault ip:55a7b9278748 sp:7ffd89b6e720 error:0 in lvm[55a7b91b2000+19e000]

My system info

uname -a
Linux arnefar-X570-UD 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a
Description:	Ubuntu 20.04 LTS
Release:	20.04
Codename:	focal

lvextend --version
  LVM version:     2.03.07(2) (2019-11-30)
  Library version: 1.02.167 (2019-11-30)
  Driver version:  4.41.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-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-dmeventd --enable-dbus-service --enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-lvmpolld --enable-notify-dbus --enable-pkgconfig --enable-readline --enable-udev_rules --enable-udev_sync

With CentOS 8, configure the lvm2 failed before precompile, and the libcpg package is required?

checking pkg-config is at least version 0.9.0... yes
checking for PKGCONFIGINIT... no
pkg-config initialized
checking for CPG... no
configure: error: Package requirements (libcpg) were not met:

Package 'libcpg', required by 'virtual:world', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables CPG_CFLAGS
and CPG_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

How to deal with this issue, thanks!

lvmteam / lvm2 Goto Github PK

lvm2's People

Contributors

Stargazers

Watchers

Forkers

lvm2's Issues

executing command: vgchange -an

Version information

Build steps

What were you trying to do?

What happened?

Steps to reproduce

time lvs

time lvs

Background

Problem

Recommend Projects

Recommend Topics

Recommend Org