<div dir="ltr">Thank you for the insight.<div>Shall I propose the patch with the following behaviour.</div><div><br></div><div>Check if "backtrace is enabled" or "compression is not enabled or not supported"</div><div>Then store the temporary uncompressed file. <br></div><div>If not skip the uncompressed file generation. </div><div><br></div><div>if( backtrace_enabled || ( compression_not_enabled || compress_not_supported))</div><div>{</div><div> generate and store uncompressed coredump</div><div>}</div><div>else</div><div>{</div><div> skip uncompressed coredump file, compress the STDIN COREFILE.</div><div>}</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 3 Dec 2016 at 23:46 Zbigniew Jędrzejewski-Szmek <<a href="mailto:zbyszek@in.waw.pl">zbyszek@in.waw.pl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Dec 02, 2016 at 05:53:59PM +0000, P.R.Dinesh wrote:<br class="gmail_msg">
> During coredump generation I could find a temporary uncompressed file<br class="gmail_msg">
> getting generated from the corefile and written to the harddisk, later this<br class="gmail_msg">
> file is getting compressed (if compression was enabled) and then the file<br class="gmail_msg">
> coredump file is stored and this temporary file is removed.<br class="gmail_msg">
<br class="gmail_msg">
We write the uncompressed file to disk to generate the backtrace.<br class="gmail_msg">
If we aren't doing that, we can just compress on-the-fly.<br class="gmail_msg">
<br class="gmail_msg">
> I have a process whose memory consumption is typically around 5GB, it<br class="gmail_msg">
> generates around 13GB of uncompressed coredump ( coredump_filter = 0x33).<br class="gmail_msg">
> Later this file is compressed to 20MB and the uncompressed file is removed.<br class="gmail_msg">
> I have set the<br class="gmail_msg">
> ProcessSizeMax=16GB<br class="gmail_msg">
> ExternalSizeMax= 16GB<br class="gmail_msg">
> But sometimes my disk doesn't have sufficient space to store this temporary<br class="gmail_msg">
> file, hence systemd-coredump aborts the coredump processing.<br class="gmail_msg">
><br class="gmail_msg">
> Is it possible to skip this temporary file generation and generate the<br class="gmail_msg">
> compressed file directly from the Corefile passed through STDIN?<br class="gmail_msg">
<br class="gmail_msg">
We could be smarter, and if we see that there isn't enough disk space<br class="gmail_msg">
to store the uncompressed core file, skip this step, and immediately<br class="gmail_msg">
try to write compressed data. I don't know how complicated that would be:<br class="gmail_msg">
we write the core either to the file or to the journal, so the code is<br class="gmail_msg">
pretty complicated. Patches are welcome ;)<br class="gmail_msg">
<br class="gmail_msg">
Zbyszek<br class="gmail_msg">
</blockquote></div></div></div>