Hello Baoquan,
(2013/08/02 12:29), Baoquan He wrote:
Hi Atsushi,
Sorry to reply so late.
By discussing with customer, their idea is below:
*******************************
The idea about a tool like this is that it works in the 1st kernel and
that it will tell you how big the vmcore will be based on what filtering
level and/or compression selected in kdump.conf. Our customer wrote a perl
script to demonstrate this, I have attached it as attachment. This perl
script only looks at uncompressed and dumplevel 31 - in the 1st kernel.
Being told about the dump size when in the 2nd (kdump/kexec kernel) is
somewhat pointless as you are not then in a position to adjust the
destination filesystem to accommodate the vmcore size should you need to.
This is proactively looking at what size is required for a vmcore.
If the kdump.conf says "filter level 11, compress", a tool to estimate
the vmcore size should take that into account, gauge what pages would
be included in that, and roughly what size that would equate to
compressed. The problem is that this is quite dynamic, so the perl
script deliberately only looks at filter level 31 (trying to work the
rest out was too hard for me to do).
**********************************
Per discussion with customer, I think the tool is expected to work in
1st kernel. With configuration file which specify the fileter level and
compression algorithm, a rough vmcore size can be given. Since they
maybe have thousands of servers, an estimated vmcore size can be very
helpful to refer to.
I understand your customer's idea, I also think it's useful for
such situation.
I'm afraid that I can't take time for developing new feature now,
but I'll accept the estimation feature if anyone makes that.
IMHO, I think /proc/kcore is better interface for analyzing live
system while it's ELF format. This is because that the logic for
/proc/vmcore might can be reused with small fix.
Thanks
Atsushi Kumagai.
Baoquan
Thanks a lot
On 07/24/13 at 04:06pm, Atsushi Kumagai wrote:
On Wed, 17 Jul 2013 15:58:30 +0800
Baoquan <[email protected]> wrote:
#makedumpfile -d31 -c/-l/-p
TYPE PAGES INCLUDED
Zero Page x no
Cache Without Private x no
Cache With Private x no
User Data x no
Free Page x no
Kernel Code x yes
Kernel Data x yes
Total Pages on system: 311000 (Just for example)
Total Pages included in kdump: 160000 (Just for example)
Estimated vmcore file size: 48000 (30% compression ratio)
##########################################################
Does this image mean that you want to run makedumpfile in 1st
kernel without generating a actual dumpfile ?
Unfortunately, makedumpfile can't work in 1st kernel because it
only supports /proc/vmcore as input data.
If you don't persist in doing in 1st kernel, your desire can be
achieved by modifying print_report() and discarding a output
data to /dev/null, and running makedumpfile via kdump as usual.
By configured dump level, total pages included in kdump can be computed.
Then with option which specify a compression algorithm, an estimated
vmcore file size can be given. Though the estimated value is changed
dynamically with time, it does give user a valuable reference.
Compression ratio is very dependent on the memory usage.
So I think it's difficult to estimate the size when any compression
algorithm is specified.
Thanks
Atsushi Kumagai
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
