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
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 ltao@redhat.com --- 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
Hi Tao,
On Sat, 8 Oct 2022 15:41:39 +0800 Tao Liu ltao@redhat.com 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 ltao@redhat.com
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
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 ltao@redhat.com --- 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
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 ltao@redhat.com
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
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 ltao@redhat.com --- 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
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 ltao@redhat.com --- 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"
Signed-off-by: Tao Liu ltao@redhat.com --- .../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
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 ltao@redhat.com
.../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
Hi Coiby,
On Thu, Oct 20, 2022 at 2:41 PM Coiby Xu coxu@redhat.com 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 ltao@redhat.com
.../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
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 coxu@redhat.com 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 ltao@redhat.com
.../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
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 coxu@redhat.com 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
Hi Coiby,
On Wed, 26 Oct 2022 11:32:30 +0800 Coiby Xu coxu@redhat.com 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 coxu@redhat.com 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
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 coxu@redhat.com 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 coxu@redhat.com 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
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
Hi Coiby, Hi Tao,
On Wed, 26 Oct 2022 11:33:01 +0800 Coiby Xu coxu@redhat.com 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 prudo@redhat.com
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
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 coxu@redhat.com 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 prudo@redhat.com
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
HI Coiby and Philipp,
On Fri, Oct 28, 2022 at 9:51 AM Coiby Xu coxu@redhat.com 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 coxu@redhat.com 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 prudo@redhat.com
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
Having this said, with the nit in the first patch fixed the series looks good to me.
Reviewed-by: Philipp Rudo prudo@redhat.com
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