mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felix Oxley <lkml@oxley.org>
To: OBATA Noboru <noboru.obata.ar@hitachi.com>
Cc: pavel@ucw.cz, hyoshiok@miraclelinux.com, linux-kernel@vger.kernel.org
Subject: Re: Linux Kernel Dump Summit 2005
Date: Wed, 12 Oct 2005 10:02:56 +0100	[thread overview]
Message-ID: <200510121002.59098.lkml@oxley.org> (raw)
In-Reply-To: <20051012.172844.59463643.noboru.obata.ar@hitachi.com>

On Wednesday 12 October 2005 09:28, OBATA Noboru wrote:

>    CMD     | NET TIME (in seconds)          | OUTPUT SIZE (in bytes)
>   ---------+--------------------------------+------------------------
>    cp      |  35.94 (usr 0.23, sys 14.16)   | 2,121,438,352 (100.0%)
>    lzf     |  54.30 (usr 35.04, sys 13.10)  | 1,959,473,330 ( 92.3%)
>    gzip -1 | 200.36 (usr 186.84, sys 11.73) | 1,938,686,487 ( 91.3%)
>   ---------+--------------------------------+------------------------
>
> Although it is too early to say lzf's compress ratio is good
> enough, its compression speed is impressive indeed.  

As you say, the speed of lzf relative to gzip is impressive.

However if the properties of the kernel dump mean that it is not suitable for 
compression then surely it is not efficient to spend any time on it.

>And the
> result also suggests that it is too early to give up the idea of
> full dump with compression.

Are you sure? :-)
If we are talking about systems with 32GB of memory then we must be taking 
about organisations who can afford an extra 100GB of disk space just for 
keeping their kernel dump files. 

I would expect that speed of recovery would always be the primary concern.
Would you agree?

regards,
Felix




  reply	other threads:[~2005-10-12  9:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 11:55 Hiro Yoshioka
2005-10-06 12:17 ` OBATA Noboru
2005-10-06 14:39   ` Hiro Yoshioka
2005-10-10  8:45   ` Pavel Machek
2005-10-12  8:28     ` OBATA Noboru
2005-10-12  9:02       ` Felix Oxley [this message]
2005-10-12  9:09         ` Pavel Machek
2005-10-12  9:56           ` Felix Oxley
2005-10-12 10:07             ` Pavel Machek
2005-10-12 18:03               ` Andy Isaacson
2005-10-12 22:34                 ` Felix Oxley
2005-10-12 11:05             ` jerome lacoste
2005-10-12 21:10               ` Felix Oxley
2005-10-18 13:47         ` OBATA Noboru
2005-10-18 14:10           ` Hugh Dickins
2005-10-19 19:00             ` Theodore Ts'o
2005-10-27  7:48               ` OBATA Noboru
2005-10-11  0:49   ` Andrew Morton
2005-10-11  4:41     ` Hiro Yoshioka
2005-10-12  8:30       ` OBATA Noboru
2005-10-13  5:49         ` Maneesh Soni
2005-10-27  7:45           ` OBATA Noboru
2005-10-13 14:28     ` Troy Heber
2005-10-17 11:19     ` Takao Indoh
2005-10-18 13:48       ` OBATA Noboru
2005-10-19  3:17         ` Takao Indoh
2005-10-27  7:45           ` OBATA Noboru
2005-10-18 14:54     ` Carsten Otte
2005-10-14  9:19 hideki.takahashi

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=200510121002.59098.lkml@oxley.org \
    --to=lkml@oxley.org \
    --cc=hyoshiok@miraclelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noboru.obata.ar@hitachi.com \
    --cc=pavel@ucw.cz \
    /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

Powered by JetHome