public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
To: chaowang@redhat.com
Cc: d.hatayama@jp.fujitsu.com, kexec@lists.infradead.org, cpw@sgi.com
Subject: Re: [PATCH] makedumpfile: reverse -c and -p if using snappy compression
Date: Tue, 10 Sep 2013 16:29:23 +0900	[thread overview]
Message-ID: <522ECA53.1060607@mxc.nes.nec.co.jp> (raw)
In-Reply-To: <20130830103337.GA6405@dhcp12-158.nay.redhat.com>

(2013/08/30 19:33), WANG Chao wrote:
> 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@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.

Yes, it should be resolved in distro side.

> -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.

I agree to WANG. -c just means to compress with zlib.
There is no mention of default format also in the man page.

    -c,-l,-p
         Compress  dump  data  by each page using zlib for -c option, lzo
         for -l option  or  snappy  for  -p  option.   (-l  option  needs
         USELZO=on and -p option needs USESNAPPY=on when building)


Thanks
Atsushi Kumagai

>> 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
>
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2013-09-10  7:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 22:08 [PATCH] makedumpfile: reverse -c and -p if using snappy compression Cliff Wickman
2013-08-29  2:58 ` WANG Chao
2013-08-29 18:46   ` Cliff Wickman
2013-08-30 10:33     ` WANG Chao
2013-09-10  7:29       ` Atsushi Kumagai [this message]
2013-08-30  3:34 ` Baoquan He
2013-08-30  9:52   ` Maxim Uvarov
2013-09-10  7:29     ` Atsushi Kumagai
2013-09-10  8:25       ` Maxim Uvarov
2013-09-10  9:57         ` HATAYAMA Daisuke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=522ECA53.1060607@mxc.nes.nec.co.jp \
    --to=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=chaowang@redhat.com \
    --cc=cpw@sgi.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox