makefumpfile tool to estimate vmcore file size

Atsushi Kumagai kumagai-atsushi at mxc.nes.nec.co.jp
Wed Jul 24 03:06:40 EDT 2013


Hello Baoquan,

On Wed, 17 Jul 2013 15:58:30 +0800
Baoquan <bhe at redhat.com> wrote:

> 
> Hi Atsushi,
> 
> Our customer want us to provide a tool to estimate the required dump
> file size based on the current system memory footprint. The following is
> detailed requirement I tried to conclude, what's your opinion?
> 
> In customer's place there are thousands of machines and they don't want
> to budget for significant increases in storage if unnecessary. This
> becomes particularly expensive with large memory (1tb+) systems booting
> off san disk.
> 
> Customer would like to achieve this by below example:
> ##########################################################
> #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



More information about the kexec mailing list