On Fri, May 27, 2022 at 01:05:57PM -0400, Vivek Goyal wrote:
So if we fill up thin pool completely, it might fail to activate
over
reboot? I do remember there were issues w.r.t filling up thin pool
compltely and it was not desired.
So above does not involve growing thin pool at all? Above just says,
query currently available space in thin pool and when it is about
to be full, stop writing to it? This is suboptimal if there is
free space in underlying volume group.
Ok, this is going to be ugly given how kdump works right now. We have
this config option core_collector where user can specify how vmcore
should be saved (dd, cp, makedumpfile, .....)
None of these tools know about streaming and thin pool extension etc.
I guess one could think of making maekdumpfile aware of thin pool. But
given there can be so many dump targets, it will be really ugly from
design point of view. Embedding knowledge of a target in a generic
filtering tool.
Alternatively we could probably write a tool of our own and pipe
makedumpfile output to it. But then user will have to specify it
in core_collector for thin pool targets only.
None of the solutions look clean or fit well into the current design.
Maybe I'm not following, but all this sounds unnecessarily complicated.
Roughly estimate largest possible kdump size (X MB).
Check that the thin pool has X MB free.
If not, lvextend -L+XMB the thin pool.
If lvextend doesn't find X MB in the vg, then quit without kdump.