lvmteam / lvm2 Goto Github PK
View Code? Open in Web Editor NEWMirror of upstream LVM2 repository
Home Page: https://gitlab.com/lvmteam/lvm2
License: GNU General Public License v2.0
Mirror of upstream LVM2 repository
Home Page: https://gitlab.com/lvmteam/lvm2
License: GNU General Public License v2.0
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
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
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: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]
Is it OK to mail the bug description and patch to [email protected] ?
I'm trying vgsplit on VG containing cached volumes. The code seems okay, except the following:
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");
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 ?
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.
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:
mknod(...)
ioctl(...)
on /dev/mapper/control
directly/dev/mapper/
with mknod(...)
SYSTEMD_READY
as equal to 0The 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"
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.
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,
(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.
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?
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,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
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.
URL: https://www.sourceware.org/pub/lvm2/LVM2.2.02.183.tgz
sha1sum: c73173d73e2ca17da254883968fbd52a6ce5c2a6
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
I remove a volume group using vgremove
while creating a different volume group with different PVs using vgcreate
.
The commands hang both hang. It looks like vgcreate
tries to acquire a lock while vgremove
holds it.
$ 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
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
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.
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;
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..
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:
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.
i want create muti lv once time ,any suggistion?
lvcreate -L 2GB -n lv01 lv02 lv03 vg01
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.
$ 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."
See also: systemd/systemd#12947
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
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;
}
I experienced inactive LVs after bootup when using lvm2-2.02.186.
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 --
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
In my environment
real 0m0.093s
user 0m0.017s
sys 0m0.009s
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
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:
lvremove
as an example to the end of the lvremove --help
outputThese 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.
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
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:
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
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.
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:~#
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
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.
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: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.
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
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!
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?
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 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.
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?
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:
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.
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
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.
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:
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:
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.
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.
./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.
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
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.