[linux-lvm] lvreduce ignores --test for implicit BLKDISCARD?

Carl-Daniel Hailfinger

2017-12-06 16:38:30 UTC

Hi,

just a quick followup: If I don't run lvreduce --test before the actual
reduce, everything works fine:

# lvreduce --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root
Finding volume group kubuntu-vg
Executing: fsadm --verbose check /dev/kubuntu-vg/root
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Executing fsck -p /dev/mapper/kubuntu--vg-root
fsck from util-linux 2.27.1
/dev/mapper/kubuntu--vg-root: clean, 211747/30212096 files, 3291346/120836096 blocks
Executing: fsadm --verbose resize /dev/kubuntu-vg/root 41943040K
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Device "/dev/mapper/kubuntu--vg-root" size is 494944649216 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/kubuntu--vg-root"
fsadm: Resizing filesystem on device "/dev/mapper/kubuntu--vg-root" to 42949672960 bytes (120836096 -> 10485760 blocks of 4096 bytes)
fsadm: Executing resize2fs /dev/mapper/kubuntu--vg-root 10485760
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/mapper/kubuntu--vg-root to 10485760 (4k) blocks.
The filesystem on /dev/mapper/kubuntu--vg-root is now 10485760 (4k) blocks long.

Archiving volume group "kubuntu-vg" metadata (seqno 3).
Reducing logical volume kubuntu-vg/root to 40.00 GiB
Size of logical volume kubuntu-vg/root changed from 460.95 GiB (118004 extents) to 40.00 GiB (10240 extents).
Loading kubuntu--vg-root table (253:1)
Suspending kubuntu--vg-root (253:1) with device flush
Resuming kubuntu--vg-root (253:1)
Creating volume group backup "/etc/lvm/backup/kubuntu-vg" (seqno 4).
Logical volume root successfully resized.

Obviously, this new run was done after reinstalling the corrupted system.

Regards,
Carl-Daniel

Post by Carl-Daniel Hailfinger
Hi,
I just lost some of the contents of a file system by running
lvreduce --test --verbose --size 40G --resizefs /dev/mapper/kubuntu-root
AFAICS this was caused by BLKDISCARD being issued despite --test. No LV
in the affected VG was mounted at the time of data loss.
Don't worry, this was a test system directly after installation, it
didn't have any important data on it.
This is a Kubuntu 16.04.3 installation on a 500 GB SSD, during setup
"whole disk with encrypted LVM" was chosen. The only non-default setting
was enabling discard support manually in dm-crypt. The exact setup is as
500 GB Samsung SSD (/dev/sda)
sda1: 512.00 MiB FAT32 (EFI System partition)
sda2: 488.00 MiB ext2 (/boot partition)
sda3: 464.78 GiB LUKS (encrypted container for LVM PV, BLKDISCARD support enabled)
# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/sda3_crypt
VG Name kubuntu-vg
PV Size 464.78 GiB / not usable 4.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 118983
Free PE 0
Allocated PE 118983
PV UUID [...]
# vgdisplay
--- Volume group ---
VG Name kubuntu-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 464.78 GiB
PE Size 4.00 MiB
Total PE 118983
Alloc PE / Size 118983 / 464.78 GiB
Free PE / Size 0 / 0
VG UUID [...]
# lvdisplay
--- Logical volume ---
LV Path /dev/kubuntu-vg/root
LV Name root
VG Name kubuntu-vg
LV UUID [...]
LV Write Access read/write
LV Creation host, time kubuntu, 2017-12-06 15:58:07 +0100
LV Status available
# open 0
LV Size 460.95 GiB
Current LE 118004
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
--- Logical volume ---
LV Path /dev/kubuntu-vg/swap_1
LV Name swap_1
VG Name kubuntu-vg
LV UUID [...]
LV Write Access read/write
LV Creation host, time kubuntu, 2017-12-06 15:58:08 +0100
LV Status available
# open 0
LV Size 3.82 GiB
Current LE 979
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
# lvreduce --version
LVM version: 2.02.133(2) (2015-10-30)
Library version: 1.02.110 (2015-10-30)
Driver version: 4.35.0
# resize2fs --version
resize2fs 1.42.13 (17-May-2015)
# cryptsetup --version
cryptsetup 1.6.6
# uname -r
4.10.0-28-generic
# cryptsetup --allow-discards luksOpen /dev/sda3 sda3_crypt
# vgchange -a y
2 logical volume(s) in volume group "kubuntu-vg" now active
# lvreduce --test --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Finding volume group kubuntu-vg
Executing: fsadm --dry-run --verbose check /dev/kubuntu-vg/root
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Dry execution fsck -p /dev/mapper/kubuntu--vg-root
Executing: fsadm --dry-run --verbose resize /dev/kubuntu-vg/root 41943040K
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Device "/dev/mapper/kubuntu--vg-root" size is 494944649216 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/kubuntu--vg-root"
fsadm: Resizing filesystem on device "/dev/mapper/kubuntu--vg-root" to 42949672960 bytes (120836096 -> 10485760 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/kubuntu--vg-root 10485760
Test mode: Skipping archiving of volume group.
Reducing logical volume kubuntu-vg/root to 40.00 GiB
Size of logical volume kubuntu-vg/root changed from 460.95 GiB (118004 extents) to 40.00 GiB (10240 extents).
Test mode: Skipping backup of volume group.
Logical volume root successfully resized.
Test mode: Wiping internal cache
Wiping internal VG cache
# lvreduce --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root
Finding volume group kubuntu-vg
Executing: fsadm --verbose check /dev/kubuntu-vg/root
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Executing fsck -p /dev/mapper/kubuntu--vg-root
fsck from util-linux 2.27.1
/dev/mapper/kubuntu--vg-root: Superblock has an invalid journal (inode 8).
CLEARED.
*** ext3 journal has been deleted - filesystem is now ext2 only ***
/dev/mapper/kubuntu--vg-root: Superblock has_journal flag is clear, but a journal is present.
CLEARED.
/dev/mapper/kubuntu--vg-root: Journal inode is not in use, but contains data. CLEARED.
/dev/mapper/kubuntu--vg-root: Inode 3801089 is in use, but has dtime set. FIXED.
/dev/mapper/kubuntu--vg-root: Inode 3801089 has a extra size (8780) which is invalid
FIXED.
/dev/mapper/kubuntu--vg-root: Inode 3801089 has compression flag set on filesystem without compression support.
/dev/mapper/kubuntu--vg-root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsadm failed: 4
Filesystem check failed.
#
# lvreduce --test --verbose --size 40G --resizefs /dev/mapper/kubuntu--vg-root
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
Finding volume group kubuntu-vg
Executing: fsadm --dry-run --verbose check /dev/kubuntu-vg/root
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Dry execution fsck -p /dev/mapper/kubuntu--vg-root
Executing: fsadm --dry-run --verbose resize /dev/kubuntu-vg/root 41943040K
fsadm: "ext4" filesystem found on "/dev/mapper/kubuntu--vg-root"
fsadm: Device "/dev/mapper/kubuntu--vg-root" size is 494944649216 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/kubuntu--vg-root"
fsadm: Resizing filesystem on device "/dev/mapper/kubuntu--vg-root" to 42949672960 bytes (120836096 -> 10485760 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/kubuntu--vg-root 10485760
Test mode: Skipping archiving of volume group.
Reducing logical volume kubuntu-vg/root to 40.00 GiB
/dev/mapper/sda3_crypt: BLKDISCARD ioctl at offset 42950721536 size 451994976256 failed: Operation not supported.
Size of logical volume kubuntu-vg/root changed from 460.95 GiB (118004 extents) to 40.00 GiB (10240 extents).
Test mode: Skipping backup of volume group.
Logical volume root successfully resized.
Test mode: Wiping internal cache
Wiping internal VG cache
The message "BLKDISCARD [...] failed" in the non-fatal test run seems
to imply that BLKDISCARD is issued even if --test is specified.
I do not know whether this is the fault of lvreduce, fsadm or resize2fs.
Any information about the possible reasons for this problem as well as
potential bugfixes would be appreciated.
Regards,
Carl-Daniel
_______________________________________________
linux-lvm mailing list
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/