On Tue, May 17 2022 at 2:34P -0400,
Tao Liu <ltao(a)redhat.com> wrote:
Hi Mike,
On Tue, May 17, 2022 at 12:58 AM Mike Snitzer <snitzer(a)redhat.com> wrote:
>
> On Mon, May 16 2022 at 3:30P -0400,
> Tao Liu <ltao(a)redhat.com> wrote:
>
> > Add Mike to CC list
> >
> > Hi Mike,
> >
> > This patch set is related to bz2034457, could you please help to
> > review it? Thank you very much!
> >
> > Thanks,
> > Tao Liu
> >
> > [1]:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...
>
> Hi,
>
> I reviewed the 4 patches.
>
> The 1st patch doesn't seem ideal, you're parsing output of 'lvs
> 2>/dev/null' (all lvm2 lvs in the system) even though you already know
> the thin device you're searching for.
>
> Since you already have the device name, I discussed with Zdenek (cc'd)
> and we arrived at something like the following suggestion:
>
> local _device_path=$1
> local _lvm2_thin_device=$(lvs -S 'lv_layout=sparse &&
lv_layout=thin' --nosuffix --noheadings -o vg_name,lv_name $_device_path)
>
> [ -n "$_lvm2_thin_device" ]
> return $?
>
Thanks for the suggestion, it looks better! I will send v2 to include
the change.
>
> The 4th patch to mount with 'sync' so that failed IO (due to inability
> to extend thin lv) strikes me as fine, except couldn't other non-thin
> mounts also fail async writes? Don't you want kdump to fail on async
> devices too? What I'm saying is: seems async mount isn't safe (at
> least not in terms of proper reporting of kdump success) regardless of
> whether lvm2 thin device is used or not.
>
I'm not an expert to fs and IO. If the async IO fails in 2nd kernel
for kdump, mostly the reason is insufficient file system space, and it
worked well for kdump in the past. However as for the case of lvm2
thinp, I found the userspace program no longer gets informed in async
when thin pool autoextend fails. So I turned to the sync flag, which
force the userspace program to wait the date been synced to disk
before exit, and it works well according to my test. But it does cost
more writing time than async...
I've consulted Eric Sandeen (cc'd) and he agrees there is a more
generic problem in the kdump userspace if it isn't able to detect
write failures without using the "sync" mount option.
kdump's job is to dump system memory as carefully as possible. Yet
you're saying kdump is using buffered IO. Buffered IO creates
additional memory use, and associated pages don't get written back
until writeback kicks in.. hence the delayed nature of write failures.
But those failures can happen with non-thinp block devices too.
Seems logical that kdump should be using direct IO to write system
memory back (rather than buffered IO). Again, using buffered IO
creates more memory use -- so you're needlessly increasing memory
reserve for kdump's use by using buffered IO.
Please take a closer look at how to properly detect write failures.
Doing so properly should make kdump work, as in detect write failure,
on any storage if it runs out of space.
Please see:
https://lwn.net/Articles/457667/
Anything short of that and you're papering over a general kdump
problem by making it seem like a thinp specific problem.
Mike
> > On Mon, May 16, 2022 at 11:26 AM Tao Liu
<ltao(a)redhat.com> 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 3 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.
> > > 3) If thin pool size-autoextend fails, the user space program will not
know due to
> > > buffered IO. So the lvm2 thinp dump target should be mounted with sync
flag, making
> > > user space program know immediately if write fails.
> > >
> > > 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.
> > >
> > > Please review.
> > >
> > > Tao Liu (4):
> > > Add lvm2 thin provision dump target checker
> > > Add lvm2-monitor.service for kdump when lvm2 thinp enabled
> > > lvm.conf should be check modified if lvm2 thinp enabled
> > > Mount the lvm2 thinp target with sync option
> > >
> > > dracut-lvm2-monitor.service | 15 +++++++++++++++
> > > dracut-module-setup.sh | 16 ++++++++++++++++
> > > kdump-lib-initramfs.sh | 25 +++++++++++++++++++++++++
> > > kdumpctl | 1 +
> > > kexec-tools.spec | 2 ++
> > > mkdumprd | 5 +++++
> > > 6 files changed, 64 insertions(+)
> > > create mode 100644 dracut-lvm2-monitor.service
> > >
> > > --
> > > 2.33.1
> > >
> >
>