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
next prev parent 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