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

From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: Maxim Uvarov <muvarov@gmail.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
	Cliff Wickman <cpw@sgi.com>, Baoquan He <bhe@redhat.com>
Subject: Re: [PATCH] makedumpfile: reverse -c and -p if using snappy compression
Date: Tue, 10 Sep 2013 18:57:09 +0900	[thread overview]
Message-ID: <522EECF5.2030004@jp.fujitsu.com> (raw)
In-Reply-To: <CAJGZr0L207Qtv3KZHTH0iTAGZ42NTD13K9jtTsFGUWpFR8DwYA@mail.gmail.com>

(2013/09/10 17:25), Maxim Uvarov wrote:
> 2013/9/10 Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>:
>> Hello Maxim,
>>
>>
>> (2013/08/30 18:52), Maxim Uvarov wrote:
>>>
>>> I think that better is to have:
>>>
>>> -cz zlib
>>> -cs snappy
>>> -cl zlo
>>
>>
>> They are main options for most users, so I don't want to change
>> them without any important reason.
>>
>>
>>> -ca - automatic selection of compression. Snappy if compiled in, then
>>> lzo. And if no snappy and lzo then zlib.
>>
>>
>> What is the selection standard ? Compression Speed ?
>> If some users prefer compression ratio to compression speed,
>> snappy isn't suitable for them.
>>
>> Each compression format has both good points and bad points,
>> so
>
>> each user should select the format manually based on the
>> purpose in any case.
>>
>
> That definitely does not work in real life. Nobody wants to set up
> something, read manual and understand all options.  More than that -
> if  you somehow updated configs and set up wrong option you will not
> receive any dump instead of receiving dump with different compression.
>
> BR,
> Maxim.

It's extreme logic. System administrator should configurate own system
with sufficient understanding, in particular on large mission critical
system. If he failed to get any dump due to wrong configuration,
it's his fault. For most systems with typical memory size, zlib still
works enough.

Also, snappy is not always better than lzo. For example, although lzo 2.0.3
is slower than snappy, lzo 2.0.6 is almost as quick as snappy, since recent
lzo is optimized enough for x86 use. Then, some distribution has lzo 2.0.3
while another lzo 2.0.6. Hence, in general, the quickest compression varies
on each systems. It's difficult for makedumpfile to choose quickest one
in general. Futhermore, makedumpfile might support more formats in the future,
the difficulty would get bigger. I don't think automation is good idea.

-- 
Thanks.
HATAYAMA, Daisuke

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