[PATCH] makedumpfile: reverse -c and -p if using snappy compression

[WANG Chao]

On 08/29/13 at 01:46pm, Cliff Wickman wrote:
> On Thu, Aug 29, 2013 at 10:58:37AM +0800, WANG Chao wrote:
> > Hi, Cliff
> > 
> > On 08/28/13 at 05:08pm, Cliff Wickman wrote:
> > > From: Cliff Wickman <cpw at sgi.com>
> > > 
> > > Reverse the meanings of -c (compression) and -p (snappy compression) if
> > > USESNAPPY is defined.
> > > 
> > > The distro kdump scripts seem to only support -c for compression.
> > > So make -c mean snappy compression if it is supported.
> > 
> > It looks like more a distro issue to me. I'm wondering if that script
> > only support -c, why do that distro compile makedumpfile with USESNAPPY?
> > 
> > I don't think other distros would like to see this change. IMHO, the
> > right thing to do is fix that kdump script on that particular distro,
> > not reverse -c and -p.
> > 
> > Thanks
> > WANG Chao
> 
> I agree that some distros could easily change their default compression
> choice, for example -c to -p in RHEL's /etc/kdump.conf.
> 
> But on the other hand SLES11 just uses KDUMP_DUMPFORMAT="compressed"
> in /etc/sysconfig/kdump.  Translation to -c occurs somewhere under the
> covers.

Instead, it's reasonable to patch SLES11 kdump utility, not upstream.

-c means using zlib and -p means using snappy. That's already established
and has been widely used.

> Makedumpfile could change the default meaning of "compressed" to snappy
> compression on the grounds that we know snappy to be much faster than
> zlib compression.  And so we default to it if available.

IMO, makedumpfile doesn't have default compression format. c/p/l means
zlib/snappy/lzo by each. If you don't specify one of them, makedumpfile
wouldn't do compression work.

You could assume -c means default compression format, but I see it means
compress with zlib.

> You would in that way make the intelligent choice without administrative
> intervention.

The intelligent choice can be made within distro specific kdump script
rather than makedumpfile.

> (You would also have to assume that crash is also be built snappy-capable
> for a system that supports snappy compression.)
> 
> I could see it either way.
> I find this patch a convenient way to make the choice.

This patch could cause regression and break current existing kdump
scripts. I wouldn't worry much about the -c (zlib) user though.

As for the people using -p to snappy compression, after upgrading their
makedumpfile, they would get zlib format dump if their kdump conf remain
untouched.

Thanks
WANG Chao