On 23 Jun 2014, at 15:05, Baoquan He <bhe at redhat.com> wrote:
> On 06/23/14 at 08:36am, Vivek Goyal wrote:
>> On Wed, Jun 11, 2014 at 08:39:05PM +0800, Baoquan He wrote:
>>> sudo makedumpfile -E -d 31 --vmcore-estimate /proc/kcore /var/crash/kcore-dump
>>>
>>> Questions:
>>> 1. Or we can get the dumpable page numbers only, then calculate the estimated
>>> vmcore size by a predifined factor if it's kdump compressed dumping. E.g if
>>> lzo dump, we assume the compression ratio is 45%, then the estimate size is
>>> equal to: (dumpable page numbers) * 4096* 45%.
>>
>> I think that we can probably not guess the saving from compression.
>> Compression ratio varies based on content of page. So if we keep it simple
>> and just calculate the number of pages which will be dumped and multiply
>> it by page size, that number will be much more accurate (for current
>> system).
>
> Yeah, this is another plan. Then the output will be the size of elf
> dump. If user configured the kdump compression, such as lzo/snappy, they
> can just estimate it by themselves. It's OK if user can accept this
> since this is much more accurate.
>
> Hi Anders,
>
> Do you have any comments on this? I found you are concerned with this
> issue too.
Hi there,
Only comment I have is that I like your approach and that I agree
we will not be able to accurately predict compression ratio. While
we could run the compression to get an accurate prediction, it
would not be accurate five minutes later, so best not to go there
at all. Just being able to tell how big the dump will be at a
specific dumplevel, uncompressed, will be very welcome by customers
and partners.
Because it allows them to gauge how much space they need to set
aside for /var/crash or where ever they need to write the dump.
The old perl script I did after speaking with Neil Horman was only
every able to predict dumplevel 31, but not all of the time is
that enough. Changing to 17 or 1 for a specific problem, they want
to know how much space they need for that.
So, I am very happy to see this effort underway. :)
Thank you,
--
Anders Rayner-Karlsson / akarlsso at redhat.com / +46-76-805-2173
Principal Technical Account Manager & Support Account Director
Red Hat Strategic Customer Engagement Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20140623/f5ed03bb/attachment.sig>
