Additional patches for 10.0.0 lvm2

Resolves: RHEL-67306 RHEL-67140

0001-RHEL10.patch

@@ -1,7 +1,7 @@
 From 5c75121219a2893f862ee18ea9717b1571894df0 Mon Sep 17 00:00:00 2001
 From: Marian Csontos <mcsontos@redhat.com>
 Date: Thu, 16 May 2024 12:12:06 +0200
-Subject: [PATCH] RHEL10
+Subject: [PATCH 1/7] RHEL10
 
 ---
  VERSION    | 2 +-

0002-lv_manip-fix-stripe-count-and-size-validation-for-RA.patch

@@ -0,0 +1,104 @@
+From 4a34959c1cc199c05b9d9d4516a05164d36370e1 Mon Sep 17 00:00:00 2001
+From: Peter Rajnoha <prajnoha@redhat.com>
+Date: Tue, 5 Nov 2024 09:26:03 +0100
+Subject: [PATCH 2/7] lv_manip: fix stripe count and size validation for RAID
+ LVs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fix stripe count and size parameter validation for RAID LVs and
+include existing automatic setting of these parameters based
+on current shape of the RAID LV in case these are not set
+on command line fully.
+
+Previously, this was done only to a certain subset given by this
+condition (where the 'stripes' is the '-i|--stripes' cmd line arg
+and  the 'stripe_size' is actually the '-I|--stripesize' cmd line arg):
+
+  !(stripes == 1 || (stripes > 1 && stripe_size))
+
+This condition is a bit harder to follow at first sight and there
+are no comments around with explanation for why this one is used,
+so let's analyze it a bit more.
+
+First, let's convert this to an equivalent condition (De Morgan law)
+so it's easier to read for humans:
+
+  stripes != 1 && !(stripes > 1 && stripe_size)
+
+Note: Both stripe and stripesize are unsigned integers, so they can't be negative.
+
+Now, based on that condition, we were running the code to deduce the
+stripe/stripesize and do the checks ("the code") only if both of these
+are true:
+
+  - stripes is different from 1
+
+  - we don't have stripes > 1 and stripe_size defined at the same time
+
+But this is not correct in all cases, because:
+
+  A) if someone uses stripes = 0, then "the code" is executed
+    (correct)
+
+  B) if someone uses stripes = 1, then "the code" is not executed
+    (wrong: we still need to be able to check the args against
+            existing RAID LV stripes whether it matches)
+
+  - if someone uses stripes > 1, then "the code" is:
+
+     C) if stripe_size = 0, executed
+       (correct)
+
+     D) if stripe_size > 0, not executed
+       (wrong: we still want to check against existing RAID LV stripes)
+
+Current issues with this condition:
+  The B) ends up with segfault.
+
+    ❯ lvextend -i 1 -l+1 vg/lvol0
+      Rounding size 4.00 MiB (1 extents) up to stripe boundary size 8.00 MiB (2 extents).
+    Segmentation fault (core dumped)
+
+  The D) ends up with errors like:
+
+    ❯ lvextend -i 3 -l+1 -I128k vg/lvol0
+      Rounding size 4.00 MiB (1 extents) up to stripe boundary size 8.00 MiB (2 extents).
+      Rounding size (4 extents) up to stripe boundary size for segment (5 extents).
+      Size of logical volume vg/lvol0 changed from 8.00 MiB (2 extents) to 20.00 MiB (5 extents).
+      LV lvol0: segment 1 with len=5  has inconsistent area_len 3
+      Couldn't read all logical volumes for volume group vg.
+      Failed to write VG vg.
+
+Conclusion:
+  The condition needs to be removed so we always run "the code" to check
+  given striping args given on command line against existing RAID LV
+  striping. The reason is that we don't want to allow changing stripe
+  count for RAID LVs through lvextend and we need to end up with the
+  error:
+    "Unable to extend <RAID segment type> segment type with different number of stripes"
+
+  (We do support changing the striping by lvconvert's reshaping functionality only).
+
+(cherry picked from commit b5249fa3c20fe5d9e1d4811e7e5bfd957b15a820)
+---
+ lib/metadata/lv_manip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/metadata/lv_manip.c b/lib/metadata/lv_manip.c
+index a1d4f641a..e14947357 100644
+--- a/lib/metadata/lv_manip.c
++++ b/lib/metadata/lv_manip.c
+@@ -5468,7 +5468,7 @@ static int _lvresize_adjust_extents(struct logical_volume *lv,
+ 		} else if (seg_is_raid0(seg_last)) {
+ 			lp->stripes = seg_last->area_count;
+ 			lp->stripe_size = seg_last->stripe_size;
+-		} else if (!(lp->stripes == 1 || (lp->stripes > 1 && lp->stripe_size))) {
++		} else {
+ 			/* If extending, find stripes, stripesize & size of last segment */
+ 			/* FIXME Don't assume mirror seg will always be AREA_LV */
+ 			/* FIXME We will need to support resize for metadata LV as well,
+-- 
+2.47.0
+

0003-lv_manip-use-the-same-param-validation-for-RAID-0-as.patch

@@ -0,0 +1,30 @@
+From f006e040090f9f3466c5e789157903607447a08e Mon Sep 17 00:00:00 2001
+From: Peter Rajnoha <prajnoha@redhat.com>
+Date: Tue, 5 Nov 2024 14:48:23 +0100
+Subject: [PATCH 3/7] lv_manip: use the same param validation for RAID 0 as for
+ RAID 1/4/5/6
+
+This actually reverts commit 83ae675f8df53010c984b78d0318d0d92d5ac83a.
+
+(cherry picked from commit 1d8a4c4817895f45a5fee00ccf721b351e5a4668)
+---
+ lib/metadata/lv_manip.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/lib/metadata/lv_manip.c b/lib/metadata/lv_manip.c
+index e14947357..15a7f3c9a 100644
+--- a/lib/metadata/lv_manip.c
++++ b/lib/metadata/lv_manip.c
+@@ -5465,9 +5465,6 @@ static int _lvresize_adjust_extents(struct logical_volume *lv,
+ 			/* FIXME Warn if command line values are being overridden? */
+ 			lp->stripes = seg_last->area_count / seg_mirrors;
+ 			lp->stripe_size = seg_last->stripe_size;
+-		} else if (seg_is_raid0(seg_last)) {
+-			lp->stripes = seg_last->area_count;
+-			lp->stripe_size = seg_last->stripe_size;
+ 		} else {
+ 			/* If extending, find stripes, stripesize & size of last segment */
+ 			/* FIXME Don't assume mirror seg will always be AREA_LV */
+-- 
+2.47.0
+

0004-tests-remove-superfluous-a-option-for-df-used-in-lvr.patch

@@ -0,0 +1,31 @@
+From a6b5d4dad0e71c2774edb29bb087c84bfac53210 Mon Sep 17 00:00:00 2001
+From: Peter Rajnoha <prajnoha@redhat.com>
+Date: Tue, 5 Nov 2024 14:20:59 +0100
+Subject: [PATCH 4/7] tests: remove superfluous -a option for df used in
+ lvresize-xfs.sh
+
+The df -a looks at whole system and it returns an error code in case
+there's an inaccessible fs which is not even part of the testing environment.
+The -a for df is not actually needed here in the lvresize-xfs test, so remove it.
+
+(cherry picked from commit a2ca20dad98f4d7389d449672b3ff0b16858f02b)
+---
+ test/shell/lvresize-xfs.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/shell/lvresize-xfs.sh b/test/shell/lvresize-xfs.sh
+index da204dac6..87fbf6f9d 100644
+--- a/test/shell/lvresize-xfs.sh
++++ b/test/shell/lvresize-xfs.sh
+@@ -113,7 +113,7 @@ dd if=/dev/zero of="$mount_dir_space/zeros1" bs=1M count=20 oflag=direct
+ # succeeds, then the xfs extend fails because it cannot be done unmounted
+ not lvextend --fs resize --fsmode offline -L+20M $vg/$lv
+ check lv_field $vg/$lv lv_size "320.00m"
+-df -a | tee dfa
++df | tee dfa
+ grep "$mount_dir_space" dfa
+ df --output=size "$mount_dir_space" |tee df2
+ # fs not extended so fs size not changed
+-- 
+2.47.0
+

0005-WHATS_NEW-update.patch

@@ -0,0 +1,26 @@
+From 38177186f79c44ba62aca80bdfe1b72ad2d6e84c Mon Sep 17 00:00:00 2001
+From: Peter Rajnoha <prajnoha@redhat.com>
+Date: Wed, 6 Nov 2024 10:39:27 +0100
+Subject: [PATCH 5/7] WHATS_NEW: update
+
+(cherry picked from commit 44a04b71f8e8ff730b5538c4b6323041cf904ece)
+---
+ WHATS_NEW | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/WHATS_NEW b/WHATS_NEW
+index 85ffe0d0c..d07a1eaeb 100644
+--- a/WHATS_NEW
++++ b/WHATS_NEW
+@@ -1,3 +1,8 @@
++Version 2.03.29 - 
++==================
++  Fix segfault/VG write error for raid LV lvextend -i|--stripes -I|--stripesize.
++  Revert ignore -i|--stripes, -I|--stripesize for lvextend on raid0 LV (2.03.27).
++
+ Version 2.03.28 - 04th November 2024
+ ====================================
+   Use radix_tree to lookup for UUID within committed metadata.
+-- 
+2.47.0
+

0006-vdo-fix-input-units-for-minimim_io_size.patch

@@ -0,0 +1,59 @@
+From 9a735a3998b96adf8259759b4c228c308327a54d Mon Sep 17 00:00:00 2001
+From: Zdenek Kabelac <zkabelac@redhat.com>
+Date: Fri, 8 Nov 2024 16:12:30 +0100
+Subject: [PATCH 6/7] vdo: fix input units for minimim_io_size
+
+When specifying minimum_io_size with --vdosettings,
+command assumed wrong unit (sectors).
+
+So '--vdosettings minimum_io_size=512|4096' resulted into
+an error that only 512 or 4096 values are allowed, but
+at the same time values  1 or 8 were accepted.
+
+So fix by converting any number >= 512 to 'sectors' and
+keep input of 1 or 8 still valid if anyone has been using
+this before.
+
+So now we take  512 or 4096  and still also  1 or 8 with the
+same effect.
+
+Also correct the 'error' message when invalid minimum_io_size
+is specified.
+
+(cherry picked from commit 158d3243b638f50f62c60128168c21840787f1ab)
+---
+ device_mapper/vdo/vdo_target.c | 2 +-
+ tools/toollib.c                | 4 ++++
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/device_mapper/vdo/vdo_target.c b/device_mapper/vdo/vdo_target.c
+index a8a753e39..cdd3dbe6d 100644
+--- a/device_mapper/vdo/vdo_target.c
++++ b/device_mapper/vdo/vdo_target.c
+@@ -28,7 +28,7 @@ bool dm_vdo_validate_target_params(const struct dm_vdo_target_params *vtp,
+ 	if ((vtp->minimum_io_size != (512 >> SECTOR_SHIFT)) &&
+ 	    (vtp->minimum_io_size != (4096 >> SECTOR_SHIFT))) {
+ 		log_error("VDO minimum io size %u is unsupported [512, 4096].",
+-			  vtp->minimum_io_size);
++			  (vtp->minimum_io_size << SECTOR_SHIFT));
+ 		valid = false;
+ 	}
+ 
+diff --git a/tools/toollib.c b/tools/toollib.c
+index dcb6c8f4f..f854d17c5 100644
+--- a/tools/toollib.c
++++ b/tools/toollib.c
+@@ -1372,6 +1372,10 @@ int get_vdo_settings(struct cmd_context *cmd,
+ 			u |= VDO_CHANGE_ONLINE;
+ 	}
+ 
++	/* store size in sector units */
++	if (vtp->minimum_io_size >= 512)
++		vtp->minimum_io_size >>= SECTOR_SHIFT;
++
+ 	// validation of updated VDO option
+ 	if (!dm_vdo_validate_target_params(vtp, 0 /* vdo_size */))
+ 		goto_out;
+-- 
+2.47.0
+

0007-tests-check-vdo-minimum_io_size.patch

@@ -0,0 +1,33 @@
+From cd28cd0158b3e8f618472b2e2d50d95f6f20a2ba Mon Sep 17 00:00:00 2001
+From: Zdenek Kabelac <zkabelac@redhat.com>
+Date: Fri, 8 Nov 2024 16:38:29 +0100
+Subject: [PATCH 7/7] tests: check vdo minimum_io_size
+
+(cherry picked from commit dcac774f0982470b29bf04f27b6394fe27c4df71)
+---
+ test/shell/lvcreate-vdo.sh | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/test/shell/lvcreate-vdo.sh b/test/shell/lvcreate-vdo.sh
+index b24801375..87d6f98a1 100644
+--- a/test/shell/lvcreate-vdo.sh
++++ b/test/shell/lvcreate-vdo.sh
+@@ -89,4 +89,15 @@ check lv_field $vg/$lv1 vdo_ack_threads "4"
+ lvs -a $vg
+ lvremove -ff $vg
+ 
++lvcreate --type vdo --vdosettings 'minimum_io_size=512' -L10G -V1T -ky -n $lv1 $vg
++check lv_field $vg/$lv1 vdo_minimum_io_size "512b"
++lvremove -ff $vg
++
++lvcreate --type vdo --vdosettings 'minimum_io_size=4096' -L10G -V1T -ky -n $lv1 $vg
++check lv_field $vg/$lv1 vdo_minimum_io_size "4.00k"
++lvremove -ff $vg
++
++# only 512 or 4096 are valid values  (and eventually 1 or 8 sectors)
++not lvcreate --type vdo --vdosettings 'minimum_io_size=8000' -L10G -V1T -ky -n $lv1 $vg
++
+ vgremove -ff $vg
+-- 
+2.47.0
+

lvm2.spec

@@ -47,6 +47,12 @@ License: GPL-2.0-only
 URL: https://sourceware.org/lvm2
 Source0: https://sourceware.org/pub/lvm2/releases/LVM2.%{version}.tgz
 Patch1: 0001-RHEL10.patch
+Patch2: 0002-lv_manip-fix-stripe-count-and-size-validation-for-RA.patch
+Patch3: 0003-lv_manip-use-the-same-param-validation-for-RAID-0-as.patch
+Patch4: 0004-tests-remove-superfluous-a-option-for-df-used-in-lvr.patch
+Patch5: 0005-WHATS_NEW-update.patch
+Patch6: 0006-vdo-fix-input-units-for-minimim_io_size.patch
+Patch7: 0007-tests-check-vdo-minimum_io_size.patch
 
 BuildRequires: make
 BuildRequires: gcc
@@ -647,6 +653,10 @@ An extensive functional testsuite for LVM2.
 %endif
 
 %changelog
+* Wed Nov 13 2024 Marian Csontos <mcsontos@redhat.com> - 2.03.28-2
+- Fix input units for VDO LV's minimim_io_size.
+- Fix stripe count and validation for RAID LVs.
+
 * Tue Nov 05 2024 Marian Csontos <mcsontos@redhat.com> - 2.03.28-1
 - Update to upstream version 2.03.28.
 - See WHATS_NEW and WHATS_NEW_DM for more information.