On 5/18/22 10:45 AM, Mike Snitzer wrote:
On Tue, May 17 2022 at 2:34P -0400,
Tao Liu <ltao(a)redhat.com> wrote:
...
> 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.
(cc: vivek, who may have thoughts on buffered IO vs direct IO)
But those failures can happen with non-thinp block devices too.
Exactly.
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.
Yep. If you want to know if your buffered write succeeded or not, you
have several options, including calling fsync() and handling any errors.
The article above goes into much more detail.
This should be done regardless of the storage type; there is no need to
single out thinp here. IO can fail for any number of reasons, on any type
of storage. You should always make the proper data integrity syscalls
and do error handling if you care about the results of your buffered write()
calls.
Thanks,
-Eric
Mike