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. Baoquan Thanks a lot On 07/24/13 at 04:06pm, Atsushi Kumagai wrote: > On Wed, 17 Jul 2013 15:58:30 +0800 > Baoquan <bhe at redhat.com> 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 > kexec at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -------------- next part -------------- A non-text attachment was scrubbed... Name: vmcore-size-guess.pl Type: application/x-perl Size: 1943 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/kexec/attachments/20130802/1f6c9d43/attachment.pl>
