Dne 27. 05. 22 v 19:40 Zdenek Kabelac napsal(a):
Dne 27. 05. 22 v 19:26 Vivek Goyal napsal(a):
On Fri, May 27, 2022 at 12:16:38PM -0500, David Teigland wrote:
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.
Estimation is hard. We could just look at raw (unfiltered /proc/vmcore size) and extend it. But problem there is we also support kdump on multi terabyte machines. And after filtering final vmcore could be just few GB. So extending thin pool to say 12TB might very well fail and we fail to save dump.
May be use above trick for dd and cp core_collectors as they will not filter anything.
And for makedumpfile, run it twice. First run only gives size estimate and second run actually saves the dump. And do this only for thin volumes targets. This will almost double dump saving time.
So ideally it will be nice if we can enable automatic thin pool extension from initramfs.
For kdump environment - this is certainly not ideal - is this itself requires lot of RAM - buffered processing should be doable even in plain bash - if you can pipe 'dd' to it.
As mentioned previously - it would be also good to make sure thin-pool leaves some 'configured' free space - so i.e. those multiTIB do not overfill thin-pool and make possibly system hard to use after such captured kdump (although one could imagine) just to 'drop' kdump if thin-pool runs over some threshold) to keep things simple.
(So i.e. if kdump fills thinpool over >99% - drop it - so use could use thin-pool after reboot - better to have usable system in this case I'd say)
Actually - since you are in 'ramdisk' and you are the 'only' user - there is possibly even more simple way -
you could write your 'very own' autoextending 'shell' - something in naive approximation:
while kdumping do
lvextend --use-policies
if no_more_free_space then kill dumping process (use 'dmsetup --force remove thinLV - replaces with error target) & lvremove thinLV ; happy_reboot_without_kdump
sleep 5
done