[PATCH v6 0/5] Add lvm2 thin provision support for kdump

[Tao Liu]

Thin provision is a mechanism that you can allocate a lvm volume which has
a large virtual size for file systems but actually in a small physical
size. The physical size can be autoextended in use if thin pool reached a
threshold specified in /etc/lvm/lvm.conf.

There are 2 works should be handled when enable lvm2 thinp for kdump:

1) Check if the dump target device or directory is thinp device.
2) Monitor the thin pool and autoextend its size when it reached the threshold
   during kdump.

According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
be handled particularly.

v1 -> v2:

1) Modified the usage of lvs cmd when check if target is lvm2 thinp
   device.
2) Removed the sync flag way of mounting for lvm2 thinp target
   during kdump, use "sync -f vmcore" to force sync data, and handle
   the error if fails.

v2 -> v3:

1) Removed "sync -f vmcore" patch out of the patch set, for it is
addressing an issue which is not specifically to lvm2 thinp support for
kdump.

v3 -> v4:

1) Removed lvm2-monitor.service, implemented the monitor service with
   a loop function within a shell script instead.
2) Add lvm2 thinp support for dump_raw, for it is addressing the similar
   issue as dump_fs.
3) Dave suggested me to implement the lvm2 thin support in dracut
   modules instead of kexec-tools. If you are OK with the loop-function-shell-script
   technical way, I will give a try to migrate it to dracut.

v4 -> v5:

1) A new 80lvmthinpool-monitor module [1] has been integrated in dracut.
   Now we simply depend on it.
2) Add lvm2 thin provision selftest.

[1]: https://github.com/dracutdevs/dracut/pull/1842

v5 -> v6:

1) Code refactoring based on Philipp's comments.
2) Print warning if lvmthinpool-monitor module is not exist.

Tao Liu (5):
  Add lvm2 thin provision dump target checker
  lvm.conf should be check modified if lvm2 thinp enabled
  Add dependency of dracut lvmthinpool-monitor module
  selftest: Only iterate the .sh files for test execution
  selftest: Add lvm2 thin provision for kdump test

dracut-module-setup.sh                        |  8 +++
 kdump-lib-initramfs.sh                        | 10 ++++
 kdump-lib.sh                                  |  6 ++
 kdumpctl                                      |  1 +
 tests/scripts/run-test.sh                     |  3 +-
 .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
 .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
 7 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
 create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf

[PATCH v6 1/5] Add lvm2 thin provision dump target checker

[Tao Liu]

We need to check if a directory or a device is lvm2 thinp target.

First, we use get_block_dump_target() to convert dump path into
block device, then we check if the device is lvm2 thinp target by
cmd lvs.

is_lvm2_thinp_device is now located in kdump-lib-initramfs.sh, for it
will be used in 2nd kernel. is_lvm2_thinp_dump_target is located in
kdump-lib.sh, for it is only used in 1st kernel, and it has dependencies
which exist in kdump-lib.sh.

Signed-off-by: Tao Liu 
---
 kdump-lib-initramfs.sh | 9 +++++++++
 kdump-lib.sh           | 6 ++++++
 2 files changed, 15 insertions(+)

diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
index e982b14..5cba8ce 100755
--- a/kdump-lib-initramfs.sh
+++ b/kdump-lib-initramfs.sh
@@ -153,3 +153,12 @@ is_fs_dump_target()
 {
    [ -n "$(kdump_get_conf_val "ext[234]|xfs|btrfs|minix|virtiofs")" ]
 }
+
+is_lvm2_thinp_device()
+{
+	_device_path=$1
+	_lvm2_thin_device=$(lvm lvs -S 'lv_layout=sparse && lv_layout=thin' \
+		--nosuffix --noheadings -o vg_name,lv_name "$_device_path" 2>/dev/null)
+
+	[ -n "$_lvm2_thin_device" ]
+}
\ No newline at end of file
diff --git a/kdump-lib.sh b/kdump-lib.sh
index 817652d..b4cc146 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -113,6 +113,12 @@ is_dump_to_rootfs()
    [[ $(kdump_get_conf_val 'failure_action|default') == dump_to_rootfs ]]
 }

+is_lvm2_thinp_dump_target()
+{
+	_target=$(get_block_dump_target)
+	[ -n "$_target" ] && is_lvm2_thinp_device "$_target"
+}
+
 get_failure_action_target()
 {
    local _target

[PATCH v6 1/5] Add lvm2 thin provision dump target checker

[Philipp Rudo]

Hi Tao,

On Sat,  8 Oct 2022 15:41:39 +0800
Tao Liu  wrote:
> We need to check if a directory or a device is lvm2 thinp target.
>
> First, we use get_block_dump_target() to convert dump path into
> block device, then we check if the device is lvm2 thinp target by
> cmd lvs.
>
> is_lvm2_thinp_device is now located in kdump-lib-initramfs.sh, for it
> will be used in 2nd kernel. is_lvm2_thinp_dump_target is located in
> kdump-lib.sh, for it is only used in 1st kernel, and it has dependencies
> which exist in kdump-lib.sh.
> Signed-off-by: Tao Liu
>
> kdump-lib-initramfs.sh | 9 +++++++++
>  kdump-lib.sh           | 6 ++++++
>  2 files changed, 15 insertions(+)
>
> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
> index e982b14..5cba8ce 100755
> --- a/kdump-lib-initramfs.sh
> +++ b/kdump-lib-initramfs.sh
> @@ -153,3 +153,12 @@ is_fs_dump_target()
>  {
>    [ -n "$(kdump_get_conf_val "ext[234]|xfs|btrfs|minix|virtiofs")" ]
>  }
>
> +is_lvm2_thinp_device()
> +{
> _device_path=$1
> _lvm2_thin_device=$(lvm lvs -S 'lv_layout=sparse && lv_layout=thin' \
> --nosuffix --noheadings -o vg_name,lv_name "$_device_path" 2>/dev/null)
> [ -n "$_lvm2_thin_device" ]
>
> +}
> \ No newline at end of file
> diff --git a/kdump-lib.sh b/kdump-lib.sh
> index 817652d..b4cc146 100755
> --- a/kdump-lib.sh
> +++ b/kdump-lib.sh
> @@ -113,6 +113,12 @@ is_dump_to_rootfs()
>    [[ $(kdump_get_conf_val 'failure_action|default') == dump_to_rootfs ]]
>  }
>
> +is_lvm2_thinp_dump_target()
> +{
> _target=$(get_block_dump_target)

^
    local

Other than that the series looks really good.

Thanks
Philipp
> [ -n "$_target" ] && is_lvm2_thinp_device "$_target"
>
> +}
>
> get_failure_action_target()
>  {
>    local _target

[PATCH v6 2/5] lvm.conf should be check modified if lvm2 thinp enabled

[Tao Liu]

lvm2 relies on /etc/lvm/lvm.conf to determine its behaviour. The
important configs such as thin_pool_autoextend_threshold and
thin_pool_autoextend_percent will be used during kdump in 2nd
kernel. So if the file is modified, the initramfs should be
rebuild to include the latest.

Signed-off-by: Tao Liu 
---
 kdump-lib-initramfs.sh | 1 +
 kdumpctl               | 1 +
 2 files changed, 2 insertions(+)

diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
index 5cba8ce..d11a55c 100755
--- a/kdump-lib-initramfs.sh
+++ b/kdump-lib-initramfs.sh
@@ -8,6 +8,7 @@ DEFAULT_SSHKEY="/root/.ssh/kdump_id_rsa"
 KDUMP_CONFIG_FILE="/etc/kdump.conf"
 FENCE_KDUMP_CONFIG_FILE="/etc/sysconfig/fence_kdump"
 FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
+LVM_CONF="/etc/lvm/lvm.conf"

# Read kdump config in well formated style
 kdump_read_conf()
diff --git a/kdumpctl b/kdumpctl
index c7efa2c..4357cda 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -390,6 +390,7 @@ check_files_modified()

# HOOKS is mandatory and need to check the modification time
    files="$files $HOOKS"
+	is_lvm2_thinp_dump_target && files="$files $LVM_CONF"
    check_exist "$files" && check_executable "$EXTRA_BINS" || return 2

for file in $files; do

[PATCH v6 2/5] lvm.conf should be check modified if lvm2 thinp enabled

[Coiby Xu]

On Sat, Oct 08, 2022 at 03:41:40PM +0800, Tao Liu wrote:
> lvm2 relies on /etc/lvm/lvm.conf to determine its behaviour. The
> important configs such as thin_pool_autoextend_threshold and
> thin_pool_autoextend_percent will be used during kdump in 2nd
> kernel. So if the file is modified, the initramfs should be
> rebuild to include the latest.
> Signed-off-by: Tao Liu
>
> kdump-lib-initramfs.sh | 1 +
> kdumpctl               | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/kdump-lib-initramfs.sh b/kdump-lib-initramfs.sh
> index 5cba8ce..d11a55c 100755
> --- a/kdump-lib-initramfs.sh
> +++ b/kdump-lib-initramfs.sh
> @@ -8,6 +8,7 @@ DEFAULT_SSHKEY="/root/.ssh/kdump_id_rsa"
> KDUMP_CONFIG_FILE="/etc/kdump.conf"
> FENCE_KDUMP_CONFIG_FILE="/etc/sysconfig/fence_kdump"
> FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
> +LVM_CONF="/etc/lvm/lvm.conf"

Note currently shellcheck sounded a false alarm[1],
   In kdump-lib-initramfs.sh line 12:
   LVM_CONF="/etc/lvm/lvm.conf"
   ^------^ SC2034 (warning): LVM_CONF appears unused. Verify use (or export if used externally).

For those who may concern, I've created an issue for shellcheck [2].

[1] https://github.com/coiby/kexec-tools/actions/runs/3326514791/jobs/5500297931
[2] https://github.com/koalaman/shellcheck/issues/2617
> # Read kdump config in well formated style
> kdump_read_conf()
> diff --git a/kdumpctl b/kdumpctl
> index c7efa2c..4357cda 100755
> --- a/kdumpctl
> +++ b/kdumpctl
> @@ -390,6 +390,7 @@ check_files_modified()
>
> # HOOKS is mandatory and need to check the modification time
>    files="$files $HOOKS"
>
> is_lvm2_thinp_dump_target && files="$files $LVM_CONF"
> check_exist "$files" && check_executable "$EXTRA_BINS" || return 2
>
> for file in $files; do
>
> -- 
> 2.33.1

[PATCH v6 3/5] Add dependency of dracut lvmthinpool-monitor module

[Tao Liu]

The 80lvmthinpool-monitor module is needed for monitor and
autoextend the size of thin pool in 2nd kernel. The module was
integrated in dracut version 057.

If lvmthinpool-monitor module is not found, we will print a warning.
Because we don't want to block the kdump process when the thin pool
capacity is enough and no monitor-and-autoextend actually needed.

Signed-off-by: Tao Liu 
---
 dracut-module-setup.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index a790a93..38d2a85 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -40,6 +40,14 @@ depends() {
         _dep="$_dep ssh-client"
     fi

+    if is_lvm2_thinp_dump_target; then
+        if dracut --list-modules | grep -q lvmthinpool-monitor; then
+            add_opt_module lvmthinpool-monitor
+        else
+            dwarning "Required lvmthinpool-monitor modules is missing! Please upgrade dracut >= 057."
+        fi
+    fi
+
     if [[ "$(uname -m)" == "s390x" ]]; then
         _dep="$_dep znet"
     fi

[PATCH v6 4/5] selftest: Only iterate the .sh files for test execution

[Tao Liu]

Previously, all files within $TESTCASEDIR/$test_case are regarded
as shell script files for testing. However there might be config
files under the directory. So let's only iterate the .sh files.

Signed-off-by: Tao Liu 
---
 tests/scripts/run-test.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tests/scripts/run-test.sh b/tests/scripts/run-test.sh
index 1501db4..0b589f7 100755
--- a/tests/scripts/run-test.sh
+++ b/tests/scripts/run-test.sh
@@ -85,8 +85,7 @@ for test_case in $testcases; do
    results[$test_case]="<Test Skipped>"

testdir=$TESTCASEDIR/$test_case
-	script_num=$(ls -1 $testdir | wc -l)
-	scripts=$(ls -r -1 $testdir | tr '\n' ' ')
+	scripts=$(ls -r -1 $testdir | egrep ".sh$" | tr '\n' ' ')
    test_outputs=""
    read main_script aux_script <<< "$scripts"

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Tao Liu]

Signed-off-by: Tao Liu 
---
 .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
 .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
 2 files changed, 64 insertions(+)
 create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
 create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf

diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
new file mode 100755
index 0000000..c4ebded
--- /dev/null
+++ b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
@@ -0,0 +1,59 @@
+on_build() {
+	TEST_DIR_PREFIX=/tmp/lvm_test.XXXXXX
+	# clear TEST_DIRs if any
+	rm -rf ${TEST_DIR_PREFIX%.*}.*
+	TEST_IMG="$(mktemp -d $TEST_DIR_PREFIX)/test.img"
+
+	img_inst_pkg "lvm2"
+	img_inst $TESTDIR/scripts/testcases/lvm2-thinp-kdump/lvm.conf  /etc/lvm/
+	dd if=/dev/zero of=$TEST_IMG bs=300M count=1
+	# The test.img will be /dev/sdb 
+	img_add_qemu_cmd "-hdb $TEST_IMG"
+}
+
+on_test() {
+	VG=vg00
+	LV_THINPOOL=thinpool
+	LV_VOLUME=thinlv
+	VMCORE_PATH=var/crash
+
+	local boot_count=$(get_test_boot_count)
+
+	if [ $boot_count -eq 1 ]; then
+
+		vgcreate $VG /dev/sdb
+		# Create a small thinpool which is definitely not enough for
+		# vmcore, then create a thin volume which is definitely enough
+		# for vmcore, so we can make sure thinpool should be autoextend
+		# during runtime.
+		lvcreate -L 10M -T $VG/$LV_THINPOOL
+		lvcreate -V 300M -T $VG/$LV_THINPOOL -n $LV_VOLUME
+		mkfs.ext4 /dev/$VG/$LV_VOLUME
+		mount /dev/$VG/$LV_VOLUME /mnt
+		mkdir -p /mnt/$VMCORE_PATH
+
+		cat << EOF > /etc/kdump.conf
+ext4 /dev/$VG/$LV_VOLUME
+path /$VMCORE_PATH
+core_collector makedumpfile -l --message-level 7 -d 31
+EOF
+		kdumpctl start || test_failed "Failed to start kdump"
+
+		sync
+
+		echo 1 > /proc/sys/kernel/sysrq
+		echo c > /proc/sysrq-trigger
+
+	elif [ $boot_count -eq 2 ]; then
+		mount /dev/$VG/$LV_VOLUME /mnt
+		if has_valid_vmcore_dir /mnt/$VMCORE_PATH; then
+			test_passed
+		else
+			test_failed "Vmcore missing"
+		fi
+
+		shutdown -h 0
+	else
+		test_failed "Unexpected reboot"
+	fi
+}
diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
new file mode 100644
index 0000000..4d81fbd
--- /dev/null
+++ b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
@@ -0,0 +1,5 @@
+activation {
+	thin_pool_autoextend_threshold = 70
+	thin_pool_autoextend_percent = 20
+	monitoring = 1
+}
\ No newline at end of file

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Coiby Xu]

Hi Tao,

This test can't run on F35, right?

Although the vmcore can be dumped, vmcore seems to be invalid,

Found a vmcore dir "/mnt/var/crash/127.0.0.1-2022-10-20-06:20:33":
[    3.157266] init.sh[748]: __vtop4_x86_64: Can't get a valid pgd.
[    3.159155] init.sh[748]: readmem: Can't convert a virtual address(ffffffff9ae1a700) to physical address.
Failed to retrive dmesg from vmcore!
[    3.163699] init.sh[748]: readmem: type_addr: 0, addr:ffffffff9ae1a700, size:390
[    3.165721] init.sh[748]: check_release: Can't get the address of system_utsname.
[    3.174909] init.sh[748]: makedumpfile Failed.

On Sat, Oct 08, 2022 at 03:41:43PM +0800, Tao Liu wrote:
> Signed-off-by: Tao Liu
>
> .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> 2 files changed, 64 insertions(+)
> create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
>
> diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> new file mode 100755
> index 0000000..c4ebded
> --- /dev/null
> +++ b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> @@ -0,0 +1,59 @@
> +on_build() {
> TEST_DIR_PREFIX=/tmp/lvm_test.XXXXXX
> # clear TEST_DIRs if any
> rm -rf ${TEST_DIR_PREFIX%.*}.*
> TEST_IMG="$(mktemp -d $TEST_DIR_PREFIX)/test.img"
> img_inst_pkg "lvm2"
> img_inst $TESTDIR/scripts/testcases/lvm2-thinp-kdump/lvm.conf  /etc/lvm/
> dd if=/dev/zero of=$TEST_IMG bs=300M count=1
> # The test.img will be /dev/sdb
> img_add_qemu_cmd "-hdb $TEST_IMG"
>
> +}
>
> +on_test() {
> VG=vg00
> LV_THINPOOL=thinpool
> LV_VOLUME=thinlv
> VMCORE_PATH=var/crash
> local boot_count=$(get_test_boot_count)
> if [ $boot_count -eq 1 ]; then
> vgcreate $VG /dev/sdb
> # Create a small thinpool which is definitely not enough for
> # vmcore, then create a thin volume which is definitely enough
> # for vmcore, so we can make sure thinpool should be autoextend
> # during runtime.
> lvcreate -L 10M -T $VG/$LV_THINPOOL
> lvcreate -V 300M -T $VG/$LV_THINPOOL -n $LV_VOLUME
> mkfs.ext4 /dev/$VG/$LV_VOLUME
> mount /dev/$VG/$LV_VOLUME /mnt
> mkdir -p /mnt/$VMCORE_PATH
> cat << EOF > /etc/kdump.conf
>
> +ext4 /dev/$VG/$LV_VOLUME
> +path /$VMCORE_PATH
> +core_collector makedumpfile -l --message-level 7 -d 31
> +EOF
> kdumpctl start || test_failed "Failed to start kdump"
> sync
> echo 1 > /proc/sys/kernel/sysrq
> echo c > /proc/sysrq-trigger
> elif [ $boot_count -eq 2 ]; then
> mount /dev/$VG/$LV_VOLUME /mnt
> if has_valid_vmcore_dir /mnt/$VMCORE_PATH; then
> 	test_passed
> else
> 	test_failed "Vmcore missing"
> fi
> shutdown -h 0
> else
> test_failed "Unexpected reboot"
> fi
>
> +}
> diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> new file mode 100644
> index 0000000..4d81fbd
> --- /dev/null
> +++ b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> @@ -0,0 +1,5 @@
> +activation {
> thin_pool_autoextend_threshold = 70
> thin_pool_autoextend_percent = 20
> monitoring = 1
>
> +}
> \ No newline at end of file
> -- 
> 2.33.1

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Tao Liu]

Hi Coiby,

On Thu, Oct 20, 2022 at 2:41 PM Coiby Xu  wrote:
> Hi Tao,
>
> This test can't run on F35, right?

Yes, the test cannot be run on f35. It requires dracut >=057, because
the 80lvmthinpool-monitor is integrated in 057.
> Although the vmcore can be dumped, vmcore seems to be invalid,
>
> Found a vmcore dir "/mnt/var/crash/127.0.0.1-2022-10-20-06:20:33":
> [    3.157266] init.sh[748]: __vtop4_x86_64: Can't get a valid pgd.
> [    3.159155] init.sh[748]: readmem: Can't convert a virtual address(ffffffff9ae1a700) to physical address.
> Failed to retrive dmesg from vmcore!
> [    3.163699] init.sh[748]: readmem: type_addr: 0, addr:ffffffff9ae1a700, size:390
> [    3.165721] init.sh[748]: check_release: Can't get the address of system_utsname.
> [    3.174909] init.sh[748]: makedumpfile Failed.
>
> On Sat, Oct 08, 2022 at 03:41:43PM +0800, Tao Liu wrote:
> > Signed-off-by: Tao Liu
> >
> > .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> > .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> > 2 files changed, 64 insertions(+)
> > create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> >
> > diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > new file mode 100755
> > index 0000000..c4ebded
> > --- /dev/null
> > +++ b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > @@ -0,0 +1,59 @@
> > +on_build() {
> >  TEST_DIR_PREFIX=/tmp/lvm_test.XXXXXX
> >  # clear TEST_DIRs if any
> >  rm -rf ${TEST_DIR_PREFIX%.*}.*
> >  TEST_IMG="$(mktemp -d $TEST_DIR_PREFIX)/test.img"
> >  img_inst_pkg "lvm2"
> >  img_inst $TESTDIR/scripts/testcases/lvm2-thinp-kdump/lvm.conf  /etc/lvm/
> >  dd if=/dev/zero of=$TEST_IMG bs=300M count=1
> >  # The test.img will be /dev/sdb
> >  img_add_qemu_cmd "-hdb $TEST_IMG"
> >
> > +}
> >
> > +on_test() {
> >  VG=vg00
> >  LV_THINPOOL=thinpool
> >  LV_VOLUME=thinlv
> >  VMCORE_PATH=var/crash
> >  local boot_count=$(get_test_boot_count)
> >  if [ $boot_count -eq 1 ]; then
> >          vgcreate $VG /dev/sdb
> >          # Create a small thinpool which is definitely not enough for
> >          # vmcore, then create a thin volume which is definitely enough
> >          # for vmcore, so we can make sure thinpool should be autoextend
> >          # during runtime.
> >          lvcreate -L 10M -T $VG/$LV_THINPOOL
> >          lvcreate -V 300M -T $VG/$LV_THINPOOL -n $LV_VOLUME

You can see here, the thinpool is too small to hold a vmcore, without
the 80lvmthinpool-monitor module to monitor and autoextend its size,
the vmcore dumping will not be successful.

If you really want to test on f35, you can copy the
80lvmthinpool-monitor to /lib/dracut/modules.d/ of f35. Then the test
can be OK. Or you can change 10M to 400M of $VG/$LV_THINPOOL, and  dd
if=/dev/zero of=$TEST_IMG bs=400M count=1, so the size of thinpool is
enough, and 80lvmthinpool-monitor is not a necessary for the case.

Thanks,
Tao Liu
> >          mkfs.ext4 /dev/$VG/$LV_VOLUME
> >          mount /dev/$VG/$LV_VOLUME /mnt
> >          mkdir -p /mnt/$VMCORE_PATH
> >          cat << EOF > /etc/kdump.conf
> >
> > +ext4 /dev/$VG/$LV_VOLUME
> > +path /$VMCORE_PATH
> > +core_collector makedumpfile -l --message-level 7 -d 31
> > +EOF
> >          kdumpctl start || test_failed "Failed to start kdump"
> >          sync
> >          echo 1 > /proc/sys/kernel/sysrq
> >          echo c > /proc/sysrq-trigger
> >  elif [ $boot_count -eq 2 ]; then
> >          mount /dev/$VG/$LV_VOLUME /mnt
> >          if has_valid_vmcore_dir /mnt/$VMCORE_PATH; then
> >                  test_passed
> >          else
> >                  test_failed "Vmcore missing"
> >          fi
> >          shutdown -h 0
> >  else
> >          test_failed "Unexpected reboot"
> >  fi
> >
> > +}
> > diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > new file mode 100644
> > index 0000000..4d81fbd
> > --- /dev/null
> > +++ b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > @@ -0,0 +1,5 @@
> > +activation {
> >  thin_pool_autoextend_threshold = 70
> >  thin_pool_autoextend_percent = 20
> >  monitoring = 1
> >
> > +}
> > \ No newline at end of file
> > --
> > 2.33.1
>
> --
> Best regards,
> Coiby

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Coiby Xu]

On Thu, Oct 20, 2022 at 04:14:30PM +0800, Tao Liu wrote:
> Hi Coiby,
>
> On Thu, Oct 20, 2022 at 2:41 PM Coiby Xu  wrote:
> > Hi Tao,
> >
> > This test can't run on F35, right?
>
> Yes, the test cannot be run on f35. It requires dracut >=057, because
> the 80lvmthinpool-monitor is integrated in 057.

Thanks for the confirmation! I was considering to add some code to skip
this test for 35 but f35 will reach EOL one month later [1]. So there is
no need to do so.

[1] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
> > Although the vmcore can be dumped, vmcore seems to be invalid,
> >
> > Found a vmcore dir "/mnt/var/crash/127.0.0.1-2022-10-20-06:20:33":
> > [    3.157266] init.sh[748]: __vtop4_x86_64: Can't get a valid pgd.
> > [    3.159155] init.sh[748]: readmem: Can't convert a virtual address(ffffffff9ae1a700) to physical address.
> > Failed to retrive dmesg from vmcore!
> > [    3.163699] init.sh[748]: readmem: type_addr: 0, addr:ffffffff9ae1a700, size:390
> > [    3.165721] init.sh[748]: check_release: Can't get the address of system_utsname.
> > [    3.174909] init.sh[748]: makedumpfile Failed.
> >
> > On Sat, Oct 08, 2022 at 03:41:43PM +0800, Tao Liu wrote:
> > > Signed-off-by: Tao Liu
> > >
> > > .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> > > .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> > > 2 files changed, 64 insertions(+)
> > > create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > > create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > >
> > > diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > > new file mode 100755
> > > index 0000000..c4ebded
> > > --- /dev/null
> > > +++ b/tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > > @@ -0,0 +1,59 @@
> > > +on_build() {
> > >  TEST_DIR_PREFIX=/tmp/lvm_test.XXXXXX
> > >  # clear TEST_DIRs if any
> > >  rm -rf ${TEST_DIR_PREFIX%.*}.*
> > >  TEST_IMG="$(mktemp -d $TEST_DIR_PREFIX)/test.img"
> > >  img_inst_pkg "lvm2"
> > >  img_inst $TESTDIR/scripts/testcases/lvm2-thinp-kdump/lvm.conf  /etc/lvm/
> > >  dd if=/dev/zero of=$TEST_IMG bs=300M count=1
> > >  # The test.img will be /dev/sdb
> > >  img_add_qemu_cmd "-hdb $TEST_IMG"
> > >
> > > +}
> > >
> > > +on_test() {
> > >  VG=vg00
> > >  LV_THINPOOL=thinpool
> > >  LV_VOLUME=thinlv
> > >  VMCORE_PATH=var/crash
> > >  local boot_count=$(get_test_boot_count)
> > >  if [ $boot_count -eq 1 ]; then
> > >          vgcreate $VG /dev/sdb
> > >          # Create a small thinpool which is definitely not enough for
> > >          # vmcore, then create a thin volume which is definitely enough
> > >          # for vmcore, so we can make sure thinpool should be autoextend
> > >          # during runtime.
> > >          lvcreate -L 10M -T $VG/$LV_THINPOOL
> > >          lvcreate -V 300M -T $VG/$LV_THINPOOL -n $LV_VOLUME
>
> You can see here, the thinpool is too small to hold a vmcore, without
> the 80lvmthinpool-monitor module to monitor and autoextend its size,
> the vmcore dumping will not be successful.
>
> If you really want to test on f35, you can copy the
> 80lvmthinpool-monitor to /lib/dracut/modules.d/ of f35. Then the test
> can be OK. Or you can change 10M to 400M of $VG/$LV_THINPOOL, and  dd
> if=/dev/zero of=$TEST_IMG bs=400M count=1, so the size of thinpool is
> enough, and 80lvmthinpool-monitor is not a necessary for the case.
>
> Thanks,
> Tao Liu
> > >          mkfs.ext4 /dev/$VG/$LV_VOLUME
> > >          mount /dev/$VG/$LV_VOLUME /mnt
> > >          mkdir -p /mnt/$VMCORE_PATH
> > >          cat << EOF > /etc/kdump.conf
> > >
> > > +ext4 /dev/$VG/$LV_VOLUME
> > > +path /$VMCORE_PATH
> > > +core_collector makedumpfile -l --message-level 7 -d 31
> > > +EOF
> > >          kdumpctl start || test_failed "Failed to start kdump"
> > >          sync
> > >          echo 1 > /proc/sys/kernel/sysrq
> > >          echo c > /proc/sysrq-trigger
> > >  elif [ $boot_count -eq 2 ]; then
> > >          mount /dev/$VG/$LV_VOLUME /mnt
> > >          if has_valid_vmcore_dir /mnt/$VMCORE_PATH; then
> > >                  test_passed
> > >          else
> > >                  test_failed "Vmcore missing"
> > >          fi
> > >          shutdown -h 0
> > >  else
> > >          test_failed "Unexpected reboot"
> > >  fi
> > >
> > > +}
> > > diff --git a/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > > new file mode 100644
> > > index 0000000..4d81fbd
> > > --- /dev/null
> > > +++ b/tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > > @@ -0,0 +1,5 @@
> > > +activation {
> > >  thin_pool_autoextend_threshold = 70
> > >  thin_pool_autoextend_percent = 20
> > >  monitoring = 1
> > >
> > > +}
> > > \ No newline at end of file
> > > --
> > > 2.33.1
> >
> > --
> > Best regards,
> > Coiby

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Coiby Xu]

On Thu, Oct 20, 2022 at 04:14:30PM +0800, Tao Liu wrote:
> Hi Coiby,
>
> On Thu, Oct 20, 2022 at 2:41 PM Coiby Xu  wrote:
> > Hi Tao,
> >
> > This test can't run on F35, right?
>
> Yes, the test cannot be run on f35. It requires dracut >=057, because
> the 80lvmthinpool-monitor is integrated in 057.

I tried the test three times this week on Fedora-Cloud-Base-36-1.5.x86_64.qcow2
but it failed all times. One time I ran it locally and here are the
logs,

[    1.601263] kdump[517]: saving to /kdumproot/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23/
[    1.607605] kdump[522]: saving vmcore-dmesg.txt to /kdumproot/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23/
[    1.617199] kdump[528]: saving vmcore-dmesg.txt complete
[    1.619315] kdump[530]: saving vmcore
[    1.761168] device-mapper: thin: 253:2: reached low water mark for data device: sending event.
[    1.826916] device-mapper: thin: 253:2: switching pool to out-of-data-space (queue IO) mode
Copying data                                      : [100.0 %] |           eta: 0s
[    1.928425] kdump.sh[531]: The kernel version is not supported.
[    1.929227] kdump.sh[531]: The makedumpfile operation may be incomplete.

Found a vmcore dir "/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23":
Failed to retrive dmesg from vmcore!
kexec-kdump-test: TEST FAILED
Vmcore missing

I can confirm dracut-057-3.fc36.x86_64 has already been installed.

Interestingly last week I ran the test on f36, it actually succeeded 
https://github.com/coiby/kexec-tools/actions/runs/3318507193/jobs/5482528377

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Philipp Rudo]

Hi Coiby,

On Wed, 26 Oct 2022 11:32:30 +0800
Coiby Xu  wrote:
> On Thu, Oct 20, 2022 at 04:14:30PM +0800, Tao Liu wrote:
> > Hi Coiby,
> >
> > On Thu, Oct 20, 2022 at 2:41 PM Coiby Xu  wrote:
> > > Hi Tao,
> > >
> > > This test can't run on F35, right?
> >
> > Yes, the test cannot be run on f35. It requires dracut >=057, because
> > the 80lvmthinpool-monitor is integrated in 057.
>
> I tried the test three times this week on Fedora-Cloud-Base-36-1.5.x86_64.qcow2
> but it failed all times. One time I ran it locally and here are the
> logs,
>
> [    1.601263] kdump[517]: saving to /kdumproot/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23/
> [    1.607605] kdump[522]: saving vmcore-dmesg.txt to /kdumproot/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23/
> [    1.617199] kdump[528]: saving vmcore-dmesg.txt complete
> [    1.619315] kdump[530]: saving vmcore
> [    1.761168] device-mapper: thin: 253:2: reached low water mark for data device: sending event.
> [    1.826916] device-mapper: thin: 253:2: switching pool to out-of-data-space (queue IO) mode
> Copying data                                      : [100.0 %] |           eta: 0s
> [    1.928425] kdump.sh[531]: The kernel version is not supported.
> [    1.929227] kdump.sh[531]: The makedumpfile operation may be incomplete.
>
> Found a vmcore dir "/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23":
> Failed to retrive dmesg from vmcore!
> kexec-kdump-test: TEST FAILED
> Vmcore missing
>
> I can confirm dracut-057-3.fc36.x86_64 has already been installed.
>
> Interestingly last week I ran the test on f36, it actually succeeded 
> https://github.com/coiby/kexec-tools/actions/runs/3318507193/jobs/5482528377

on first sight this looks more like some kernel change to F36 broke
makedumpfile. Have you tried it with a different core collector other
than makedumpfile?

Thanks
Philipp

[PATCH v6 5/5] selftest: Add lvm2 thin provision for kdump test

[Coiby Xu]

On Thu, Oct 27, 2022 at 02:51:40PM +0200, Philipp Rudo wrote:
> Hi Coiby,
>
> On Wed, 26 Oct 2022 11:32:30 +0800
> Coiby Xu  wrote:
> > On Thu, Oct 20, 2022 at 04:14:30PM +0800, Tao Liu wrote:
> > > Hi Coiby,
> > >
> > > On Thu, Oct 20, 2022 at 2:41 PM Coiby Xu  wrote:
> > > > Hi Tao,
> > > >
> > > > This test can't run on F35, right?
> > >
> > > Yes, the test cannot be run on f35. It requires dracut >=057, because
> > > the 80lvmthinpool-monitor is integrated in 057.
> >
> > I tried the test three times this week on Fedora-Cloud-Base-36-1.5.x86_64.qcow2
> > but it failed all times. One time I ran it locally and here are the
> > logs,
> >
> > [    1.601263] kdump[517]: saving to /kdumproot/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23/
> > [    1.607605] kdump[522]: saving vmcore-dmesg.txt to /kdumproot/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23/
> > [    1.617199] kdump[528]: saving vmcore-dmesg.txt complete
> > [    1.619315] kdump[530]: saving vmcore
> > [    1.761168] device-mapper: thin: 253:2: reached low water mark for data device: sending event.
> > [    1.826916] device-mapper: thin: 253:2: switching pool to out-of-data-space (queue IO) mode
> > Copying data                                      : [100.0 %] |           eta: 0s
> > [    1.928425] kdump.sh[531]: The kernel version is not supported.
> > [    1.929227] kdump.sh[531]: The makedumpfile operation may be incomplete.
> >
> > Found a vmcore dir "/mnt/var/crash/127.0.0.1-2022-10-26-02:59:23":
> > Failed to retrive dmesg from vmcore!
> > kexec-kdump-test: TEST FAILED
> > Vmcore missing
> >
> > I can confirm dracut-057-3.fc36.x86_64 has already been installed.
> >
> > Interestingly last week I ran the test on f36, it actually succeeded
> > https://github.com/coiby/kexec-tools/actions/runs/3318507193/jobs/5482528377
>
> on first sight this looks more like some kernel change to F36 broke
> makedumpfile. Have you tried it with a different core collector other
> than makedumpfile?

Thanks to Tao's reminding, it is actually my mistake. While fixing the
network test failures, I missed the "Add lvm2 thin provision dump target
checker" patch when doing the rebasing.
> Thanks
> Philipp

[Coiby Xu]

Hi Tao,

On Sat, Oct 08, 2022 at 03:41:38PM +0800, Tao Liu wrote:
> Thin provision is a mechanism that you can allocate a lvm volume which has
> a large virtual size for file systems but actually in a small physical
> size. The physical size can be autoextended in use if thin pool reached a
> threshold specified in /etc/lvm/lvm.conf.
>
> There are 2 works should be handled when enable lvm2 thinp for kdump:
> Check if the dump target device or directory is thinp device.

Does dracut has the ability to automatically detect if a root filesystem
is lvm2 thinp? It seem dracut can build a ordinary initrd that switch
to a lvm volume root filesystem. If that's true, can we harness dracut
to it for us? If it works, I imagine NVMf-fc and infini-band may also
been supported automatically without us doing anything.
> Monitor the thin pool and autoextend its size when it reached the threshold
>
> during kdump.
>
> According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
> size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
> for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
> be handled particularly.
>
> v1 -> v2:
> Modified the usage of lvs cmd when check if target is lvm2 thinp
>
> device.
> 2) Removed the sync flag way of mounting for lvm2 thinp target
>   during kdump, use "sync -f vmcore" to force sync data, and handle
>   the error if fails.
>
> v2 -> v3:
> Removed "sync -f vmcore" patch out of the patch set, for it is
>
> addressing an issue which is not specifically to lvm2 thinp support for
> kdump.
>
> v3 -> v4:
> Removed lvm2-monitor.service, implemented the monitor service with
>
> a loop function within a shell script instead.
> 2) Add lvm2 thinp support for dump_raw, for it is addressing the similar
>   issue as dump_fs.
> 3) Dave suggested me to implement the lvm2 thin support in dracut
>   modules instead of kexec-tools. If you are OK with the loop-function-shell-script
>   technical way, I will give a try to migrate it to dracut.
>
> v4 -> v5:
> A new 80lvmthinpool-monitor module [1] has been integrated in dracut.
>
> Now we simply depend on it.
> 2) Add lvm2 thin provision selftest.
>
> v5 -> v6:
> Code refactoring based on Philipp's comments.
> Print warning if lvmthinpool-monitor module is not exist.
>
> Tao Liu (5):
>  Add lvm2 thin provision dump target checker
>  lvm.conf should be check modified if lvm2 thinp enabled
>  Add dependency of dracut lvmthinpool-monitor module
>  selftest: Only iterate the .sh files for test execution
>  selftest: Add lvm2 thin provision for kdump test
>
> dracut-module-setup.sh                        |  8 +++
> kdump-lib-initramfs.sh                        | 10 ++++
> kdump-lib.sh                                  |  6 ++
> kdumpctl                                      |  1 +
> tests/scripts/run-test.sh                     |  3 +-
> .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> 7 files changed, 90 insertions(+), 2 deletions(-)
> create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
>
> -- 
> 2.33.1

[Philipp Rudo]

Hi Coiby,
Hi Tao,

On Wed, 26 Oct 2022 11:33:01 +0800
Coiby Xu  wrote:
> Hi Tao,
>
> On Sat, Oct 08, 2022 at 03:41:38PM +0800, Tao Liu wrote:
> > Thin provision is a mechanism that you can allocate a lvm volume which has
> > a large virtual size for file systems but actually in a small physical
> > size. The physical size can be autoextended in use if thin pool reached a
> > threshold specified in /etc/lvm/lvm.conf.
> >
> > There are 2 works should be handled when enable lvm2 thinp for kdump:
> > Check if the dump target device or directory is thinp device.
>
> Does dracut has the ability to automatically detect if a root filesystem
> is lvm2 thinp? It seem dracut can build a ordinary initrd that switch
> to a lvm volume root filesystem. If that's true, can we harness dracut
> to it for us? If it works, I imagine NVMf-fc and infini-band may also
> been supported automatically without us doing anything.

that would be nice of course. However the way I see it it would only
make patch 3 obsolete. The rest of the series would need to stay the
way it is.

Having this said, with the nit in the first patch fixed the series looks
good to me.

Reviewed-by: Philipp Rudo

Thanks
Philipp
> > Monitor the thin pool and autoextend its size when it reached the threshold
> >
> > during kdump.
> >
> > According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
> > size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
> > for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
> > be handled particularly.
> >
> > v1 -> v2:
> > Modified the usage of lvs cmd when check if target is lvm2 thinp
> >
> > device.
> > 2) Removed the sync flag way of mounting for lvm2 thinp target
> >   during kdump, use "sync -f vmcore" to force sync data, and handle
> >   the error if fails.
> >
> > v2 -> v3:
> > Removed "sync -f vmcore" patch out of the patch set, for it is
> >
> > addressing an issue which is not specifically to lvm2 thinp support for
> > kdump.
> >
> > v3 -> v4:
> > Removed lvm2-monitor.service, implemented the monitor service with
> >
> > a loop function within a shell script instead.
> > 2) Add lvm2 thinp support for dump_raw, for it is addressing the similar
> >   issue as dump_fs.
> > 3) Dave suggested me to implement the lvm2 thin support in dracut
> >   modules instead of kexec-tools. If you are OK with the loop-function-shell-script
> >   technical way, I will give a try to migrate it to dracut.
> >
> > v4 -> v5:
> > A new 80lvmthinpool-monitor module [1] has been integrated in dracut.
> >
> > Now we simply depend on it.
> > 2) Add lvm2 thin provision selftest.
> >
> > v5 -> v6:
> > Code refactoring based on Philipp's comments.
> > Print warning if lvmthinpool-monitor module is not exist.
> >
> > Tao Liu (5):
> >  Add lvm2 thin provision dump target checker
> >  lvm.conf should be check modified if lvm2 thinp enabled
> >  Add dependency of dracut lvmthinpool-monitor module
> >  selftest: Only iterate the .sh files for test execution
> >  selftest: Add lvm2 thin provision for kdump test
> >
> > dracut-module-setup.sh                        |  8 +++
> > kdump-lib-initramfs.sh                        | 10 ++++
> > kdump-lib.sh                                  |  6 ++
> > kdumpctl                                      |  1 +
> > tests/scripts/run-test.sh                     |  3 +-
> > .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> > .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> > 7 files changed, 90 insertions(+), 2 deletions(-)
> > create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> >
> > -- 
> > 2.33.1

[Coiby Xu]

On Thu, Oct 27, 2022 at 02:54:25PM +0200, Philipp Rudo wrote:
> Hi Coiby,
> Hi Tao,
>
> On Wed, 26 Oct 2022 11:33:01 +0800
> Coiby Xu  wrote:
> > Hi Tao,
> >
> > On Sat, Oct 08, 2022 at 03:41:38PM +0800, Tao Liu wrote:
> > > Thin provision is a mechanism that you can allocate a lvm volume which has
> > > a large virtual size for file systems but actually in a small physical
> > > size. The physical size can be autoextended in use if thin pool reached a
> > > threshold specified in /etc/lvm/lvm.conf.
> > >
> > > There are 2 works should be handled when enable lvm2 thinp for kdump:
> > > Check if the dump target device or directory is thinp device.
> >
> > Does dracut has the ability to automatically detect if a root filesystem
> > is lvm2 thinp? It seem dracut can build a ordinary initrd that switch
> > to a lvm volume root filesystem. If that's true, can we harness dracut
> > to it for us? If it works, I imagine NVMf-fc and infini-band may also
> > been supported automatically without us doing anything.
>
> that would be nice of course. However the way I see it it would only
> make patch 3 obsolete. The rest of the series would need to stay the
> way it is.

Thanks for the reminding! Yeah, unless dracut also has the ability to
only update the initrd if truly necessary, we need patch 2 which depends
on patch 1. Basically, what I want to achieve is to avoid the need of
having some internal knowledge about lvm2 thin provision and only
need to make sure the observable behaviour is what we expect by adding
the test. But I imagine this would a long-term goal.
> Having this said, with the nit in the first patch fixed the series looks
> good to me.
>
> Reviewed-by: Philipp Rudo
>
> Thanks
> Philipp
> > > Monitor the thin pool and autoextend its size when it reached the threshold
> > >
> > > during kdump.
> > >
> > > According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
> > > size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
> > > for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
> > > be handled particularly.
> > >
> > > v1 -> v2:
> > > Modified the usage of lvs cmd when check if target is lvm2 thinp
> > >
> > > device.
> > > 2) Removed the sync flag way of mounting for lvm2 thinp target
> > >   during kdump, use "sync -f vmcore" to force sync data, and handle
> > >   the error if fails.
> > >
> > > v2 -> v3:
> > > Removed "sync -f vmcore" patch out of the patch set, for it is
> > >
> > > addressing an issue which is not specifically to lvm2 thinp support for
> > > kdump.
> > >
> > > v3 -> v4:
> > > Removed lvm2-monitor.service, implemented the monitor service with
> > >
> > > a loop function within a shell script instead.
> > > 2) Add lvm2 thinp support for dump_raw, for it is addressing the similar
> > >   issue as dump_fs.
> > > 3) Dave suggested me to implement the lvm2 thin support in dracut
> > >   modules instead of kexec-tools. If you are OK with the loop-function-shell-script
> > >   technical way, I will give a try to migrate it to dracut.
> > >
> > > v4 -> v5:
> > > A new 80lvmthinpool-monitor module [1] has been integrated in dracut.
> > >
> > > Now we simply depend on it.
> > > 2) Add lvm2 thin provision selftest.
> > >
> > > v5 -> v6:
> > > Code refactoring based on Philipp's comments.
> > > Print warning if lvmthinpool-monitor module is not exist.
> > >
> > > Tao Liu (5):
> > >  Add lvm2 thin provision dump target checker
> > >  lvm.conf should be check modified if lvm2 thinp enabled
> > >  Add dependency of dracut lvmthinpool-monitor module
> > >  selftest: Only iterate the .sh files for test execution
> > >  selftest: Add lvm2 thin provision for kdump test
> > >
> > > dracut-module-setup.sh                        |  8 +++
> > > kdump-lib-initramfs.sh                        | 10 ++++
> > > kdump-lib.sh                                  |  6 ++
> > > kdumpctl                                      |  1 +
> > > tests/scripts/run-test.sh                     |  3 +-
> > > .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> > > .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> > > 7 files changed, 90 insertions(+), 2 deletions(-)
> > > create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > > create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > >
> > > --
> > > 2.33.1

[Tao Liu]

HI Coiby and Philipp,

On Fri, Oct 28, 2022 at 9:51 AM Coiby Xu  wrote:
> On Thu, Oct 27, 2022 at 02:54:25PM +0200, Philipp Rudo wrote:
> > Hi Coiby,
> > Hi Tao,
> >
> > On Wed, 26 Oct 2022 11:33:01 +0800
> > Coiby Xu  wrote:
> > > Hi Tao,
> > >
> > > On Sat, Oct 08, 2022 at 03:41:38PM +0800, Tao Liu wrote:
> > > > Thin provision is a mechanism that you can allocate a lvm volume which has
> > > > a large virtual size for file systems but actually in a small physical
> > > > size. The physical size can be autoextended in use if thin pool reached a
> > > > threshold specified in /etc/lvm/lvm.conf.
> > > >
> > > > There are 2 works should be handled when enable lvm2 thinp for kdump:
> > > > Check if the dump target device or directory is thinp device.
> > >
> > > Does dracut has the ability to automatically detect if a root filesystem
> > > is lvm2 thinp? It seem dracut can build a ordinary initrd that switch
> > > to a lvm volume root filesystem. If that's true, can we harness dracut
> > > to it for us? If it works, I imagine NVMf-fc and infini-band may also
> > > been supported automatically without us doing anything.

Currently dracut doesn't have the ability to detect a rootfs is lvm2
thinp. As for this patchset, it relies on kexec-tools to tell dracut
if volume is lvm2 thinp and autoextend monitor service is needed. I
agree it will be a nice feature if dracut can detect lvm2 thinp rootfs
and start an autoextend monitor service in background before switch to
it. It is a long term goal to me because currently I didn't see the
need to make a lvm thinp rootfs. Nowadays the rootfs can be small
enough, considering the embedded systems or the initramfs as we do in
2nd kernel of kdump. There won't be much benefit of a lvm thinp
rootfs. Anyway I think we can do the feature when we encounter the
actual use case.

Thanks,
Tao Liu
> > that would be nice of course. However the way I see it it would only
> > make patch 3 obsolete. The rest of the series would need to stay the
> > way it is.
>
> Thanks for the reminding! Yeah, unless dracut also has the ability to
> only update the initrd if truly necessary, we need patch 2 which depends
> on patch 1. Basically, what I want to achieve is to avoid the need of
> having some internal knowledge about lvm2 thin provision and only
> need to make sure the observable behaviour is what we expect by adding
> the test. But I imagine this would a long-term goal.
> > Having this said, with the nit in the first patch fixed the series looks
> > good to me.
> >
> > Reviewed-by: Philipp Rudo
> >
> > Thanks
> > Philipp
> > > > Monitor the thin pool and autoextend its size when it reached the threshold
> > > >
> > > > during kdump.
> > > >
> > > > According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
> > > > size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
> > > > for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
> > > > be handled particularly.
> > > >
> > > > v1 -> v2:
> > > > Modified the usage of lvs cmd when check if target is lvm2 thinp
> > > >
> > > > device.
> > > > 2) Removed the sync flag way of mounting for lvm2 thinp target
> > > >   during kdump, use "sync -f vmcore" to force sync data, and handle
> > > >   the error if fails.
> > > >
> > > > v2 -> v3:
> > > > Removed "sync -f vmcore" patch out of the patch set, for it is
> > > >
> > > > addressing an issue which is not specifically to lvm2 thinp support for
> > > > kdump.
> > > >
> > > > v3 -> v4:
> > > > Removed lvm2-monitor.service, implemented the monitor service with
> > > >
> > > > a loop function within a shell script instead.
> > > > 2) Add lvm2 thinp support for dump_raw, for it is addressing the similar
> > > >   issue as dump_fs.
> > > > 3) Dave suggested me to implement the lvm2 thin support in dracut
> > > >   modules instead of kexec-tools. If you are OK with the loop-function-shell-script
> > > >   technical way, I will give a try to migrate it to dracut.
> > > >
> > > > v4 -> v5:
> > > > A new 80lvmthinpool-monitor module [1] has been integrated in dracut.
> > > >
> > > > Now we simply depend on it.
> > > > 2) Add lvm2 thin provision selftest.
> > > >
> > > > v5 -> v6:
> > > > Code refactoring based on Philipp's comments.
> > > > Print warning if lvmthinpool-monitor module is not exist.
> > > >
> > > > Tao Liu (5):
> > > >  Add lvm2 thin provision dump target checker
> > > >  lvm.conf should be check modified if lvm2 thinp enabled
> > > >  Add dependency of dracut lvmthinpool-monitor module
> > > >  selftest: Only iterate the .sh files for test execution
> > > >  selftest: Add lvm2 thin provision for kdump test
> > > >
> > > > dracut-module-setup.sh                        |  8 +++
> > > > kdump-lib-initramfs.sh                        | 10 ++++
> > > > kdump-lib.sh                                  |  6 ++
> > > > kdumpctl                                      |  1 +
> > > > tests/scripts/run-test.sh                     |  3 +-
> > > > .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> > > > .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> > > > 7 files changed, 90 insertions(+), 2 deletions(-)
> > > > create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > > > create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > > >
> > > > --
> > > > 2.33.1
>
> --
> Best regards,
> Coiby

[Coiby Xu]

> Having this said, with the nit in the first patch fixed the series looks
> good to me.
>
> Reviewed-by: Philipp Rudo

Patches merged with a trivial style fix [1], thanks to Tao and Philipp!

[1] https://github.com/coiby/kexec-tools/pull/17/checks
> Thanks
> Philipp
> > > Monitor the thin pool and autoextend its size when it reached the threshold
> > >
> > > during kdump.
> > >
> > > According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
> > > size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
> > > for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
> > > be handled particularly.
> > >
> > > v1 -> v2:
> > > Modified the usage of lvs cmd when check if target is lvm2 thinp
> > >
> > > device.
> > > 2) Removed the sync flag way of mounting for lvm2 thinp target
> > >   during kdump, use "sync -f vmcore" to force sync data, and handle
> > >   the error if fails.
> > >
> > > v2 -> v3:
> > > Removed "sync -f vmcore" patch out of the patch set, for it is
> > >
> > > addressing an issue which is not specifically to lvm2 thinp support for
> > > kdump.
> > >
> > > v3 -> v4:
> > > Removed lvm2-monitor.service, implemented the monitor service with
> > >
> > > a loop function within a shell script instead.
> > > 2) Add lvm2 thinp support for dump_raw, for it is addressing the similar
> > >   issue as dump_fs.
> > > 3) Dave suggested me to implement the lvm2 thin support in dracut
> > >   modules instead of kexec-tools. If you are OK with the loop-function-shell-script
> > >   technical way, I will give a try to migrate it to dracut.
> > >
> > > v4 -> v5:
> > > A new 80lvmthinpool-monitor module [1] has been integrated in dracut.
> > >
> > > Now we simply depend on it.
> > > 2) Add lvm2 thin provision selftest.
> > >
> > > v5 -> v6:
> > > Code refactoring based on Philipp's comments.
> > > Print warning if lvmthinpool-monitor module is not exist.
> > >
> > > Tao Liu (5):
> > >  Add lvm2 thin provision dump target checker
> > >  lvm.conf should be check modified if lvm2 thinp enabled
> > >  Add dependency of dracut lvmthinpool-monitor module
> > >  selftest: Only iterate the .sh files for test execution
> > >  selftest: Add lvm2 thin provision for kdump test
> > >
> > > dracut-module-setup.sh                        |  8 +++
> > > kdump-lib-initramfs.sh                        | 10 ++++
> > > kdump-lib.sh                                  |  6 ++
> > > kdumpctl                                      |  1 +
> > > tests/scripts/run-test.sh                     |  3 +-
> > > .../lvm2-thinp-kdump/0-local-lvm2-thinp.sh    | 59 +++++++++++++++++++
> > > .../testcases/lvm2-thinp-kdump/lvm.conf       |  5 ++
> > > 7 files changed, 90 insertions(+), 2 deletions(-)
> > > create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
> > > create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
> > >
> > > --
> > > 2.33.1