From: Timothy Miller <miller@techsource.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Miquel van Smoorenburg <miquels@cistron.nl>,
linux-kernel@vger.kernel.org
Subject: Re: File system compression, not at the block layer
Date: Wed, 28 Apr 2004 18:57:08 -0400 [thread overview]
Message-ID: <409036C4.7030102@techsource.com> (raw)
In-Reply-To: <20040427203426.GB6116@openzaurus.ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>>>>Well, why not do the compression at the highest layer?
>>>>[...] doing it transparently and for all files.
>>>
>>>http://e2compr.sourceforge.net/
>>
>>It's been done (see the above URL), but given how cheap disk space has
>>gotten, and how the speed of CPU has gotten faster much more quickly
>>than disk access has, many/most people have not be interested in
>>trading off performance for space. As a result, there are race
>
>
> Is CPU_speed / disk_throughput increasing? If so, compression
> might help once again. CPU_speed / net_throughput probably is
> increasing, so compressedNFS would probably make sense.
I've always felt that way, but every time I mention it, people tell me
it's not worth the CPU overhead. For many years, I have felt that there
should be an IP socket type which was inherently compressed.
next prev parent reply other threads:[~2004-04-28 22:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-23 17:26 File system compression, not at the block layer Timothy Miller
2004-04-23 17:30 ` Miquel van Smoorenburg
2004-04-23 17:41 ` Theodore Ts'o
2004-04-23 17:57 ` Jörn Engel
2004-04-23 18:14 ` Timothy Miller
2004-04-23 18:34 ` Paul Jackson
2004-04-23 20:14 ` Joel Jaeggli
2004-04-23 20:34 ` Richard B. Johnson
2004-04-23 20:44 ` Måns Rullgård
2004-04-23 20:59 ` Richard B. Johnson
2004-04-23 21:14 ` Ben Greear
2004-04-23 21:25 ` Timothy Miller
2004-04-24 4:58 ` Ben Greear
2004-04-27 15:45 ` Timothy Miller
2004-04-23 21:18 ` Timothy Miller
2004-04-24 1:28 ` Horst von Brand
2004-04-24 2:24 ` Tom Vier
2004-04-24 7:36 ` Willy Tarreau
2004-04-24 16:02 ` Eric D. Mudama
2004-04-25 3:05 ` Horst von Brand
2004-04-25 7:29 ` Willy Tarreau
2004-04-25 19:50 ` Eric D. Mudama
2004-04-27 15:43 ` Timothy Miller
2004-04-28 0:29 ` Tom Vier
2004-04-23 21:31 ` Joel Jaeggli
2004-04-23 22:20 ` Ian Stirling
2004-04-23 23:34 ` Paul Jackson
2004-04-27 15:42 ` Timothy Miller
2004-04-27 16:02 ` Jörn Engel
2004-04-24 1:18 ` Horst von Brand
2004-04-26 10:22 ` Jörn Engel
2004-04-23 21:15 ` Timothy Miller
2004-04-23 21:36 ` Joel Jaeggli
2004-04-27 20:34 ` Pavel Machek
2004-04-28 22:57 ` Timothy Miller [this message]
2004-04-29 9:46 ` Jörn Engel
2004-04-29 9:52 ` Pavel Machek
2004-04-29 10:09 ` Jörn Engel
2004-04-29 10:19 ` Pavel Machek
2004-04-29 17:17 ` Tim Connors
2004-04-28 1:00 ` David Lang
2004-04-28 10:09 ` Jörn Engel
2004-04-28 10:21 ` Nikita Danilov
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=409036C4.7030102@techsource.com \
--to=miller@techsource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miquels@cistron.nl \
--cc=pavel@ucw.cz \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.