On 1/6/2019 9:59 PM, Dave Young wrote:
On 01/04/19 at 04:45pm, Kazuhito Hagio wrote:
> Hi,
>
> On 12/23/2018 11:17 PM, Dave Young wrote:
>> But still not sure about it. As we can see for normal kdump there will
>> be similar issue existed, eg. between C and D if a reproducible panic
>> also happens every time during late boot phase
>>
>> So it is hard to define this is early kdump only, just more likely for
>> early kdump.
>
> I agree on this. And I guess that having behavior differences between
> early and normal kdump will make kexec-tools complicated and confusing
> for users.
I also hesitate to make the kdump logic more complicated, it will become
even confusing..
Early kdump is very optional (most kdump users rarely use it), so
I'm afraid that making the kdump logic more complicated because of it
doesn't pay for now..
I think we can implement it when a request or a need to have different
actions between early and normal kdump comes.
> If so, having a common 'final_action' option in
kdump.conf also might
> be good. We can recommend users set 'final_action poweroff' for early
> kdump to avoid crash loop in the early kdump document.
Good suggestion, it might be the better.
This would be simple and give a new choice to normal kdump users, too.
I'll write a patch for this.
> As for the vmcore-filled disk issue, which also occurs with
normal
> kdump and even an one-shot panic, something like 'remove_on_fail'
> option might be helpful as a fail-safe.
Not very clear about "remove_on_fail", could you elaborate about the
suggestion? remove old vmcores or remove partial dumped files?
I mean it removes the partial dumped file when the core_collector
fails and the target disk is full. (so 'remove_on_full' is better?)
Users can select to keep the failed dump file (maybe useless) or
keep some disk space vacant.
or, something like 'disk_margin <size>' option would be safer to keep
enough space for user applications. It can remove the vmcore when dump
finished and the space of disk is less than the specified margin value.
Ideally, users should prepare a target disk only for kdump separately
from system disk and we should recommend them do so, but some of them
cannot or don't. So having such an option might be helpful for some
users.
Thanks,
Kazu