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.