Re: the " 'official' point of view" expressed by kernelnewbies.orgregarding reiser4 inclusion
From: David Masover
Date: Sun Aug 06 2006 - 19:34:50 EST
Pavel Machek wrote:
On Tue 01-08-06 11:57:10, David Masover wrote:
Horst H. von Brand wrote:
Bernd Schubert <bernd-schubert@xxxxxx> wrote:
Why not? I mean, other than TANSTAAFL, is there a
technical reason for them being mutually exclusive? I
suspect it's more "we haven't found a way yet..."
While filesystem speed is nice, it also would be great
if reiser4.x would be very robust against any kind of
Can't have both.
What does the acronym mean?
There Ain't No Such Thing As A Free Lunch.
Yes, I'm afraid redundancy/checksums kill write speed, and you need
that for robustness...
Not necessarily -- if you do it on flush, and store it near the data it
relates to, you can expect a similar impact to compression, except that
due to slow disks, the compression can actually speed things up 2x,
whereas checksums should be some insignificant amount slower than 1x.
Redundancy, sure, but checksums should be easy, and I don't see what
robustness (abilities of fsck) has to do with it.
You could have filesystem that can be tuned for reliability and tuned
for speed... but you can't have both in one filesystem instance.
That's an example of TANSTAAFL, if it's true.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/