linux-kernel - Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44D67CF6.3010905@slaphack.com>
Date:	Sun, 06 Aug 2006 19:36:22 -0400
From:	David Masover <ninja@...phack.com>
To:	Pavel Machek <pavel@....cz>
CC:	"Horst H. von Brand" <vonbrand@....utfsm.cl>,
	Bernd Schubert <bernd-schubert@....de>,
	reiserfs-list@...esys.com, Jan-Benedict Glaw <jbglaw@...-owl.de>,
	Clay Barnes <clay.barnes@...il.com>,
	Rudy Zijlstra <rudy@...ons.demon.nl>,
	Adrian Ulrich <reiser4@...nkenlights.ch>, ipso@...ppymail.ca,
	reiser@...esys.com, lkml@...productions.com, jeff@...zik.org,
	tytso@....edu, linux-kernel@...r.kernel.org
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org
 regarding reiser4 inclusion

Pavel Machek wrote:
> On Tue 01-08-06 11:57:10, David Masover wrote:
>> Horst H. von Brand wrote:
>>> Bernd Schubert <bernd-schubert@....de> wrote:
>>>> While filesystem speed is nice, it also would be great 
>>>> if reiser4.x would be very robust against any kind of 
>>>> hardware failures.
>>> Can't have both.
>> 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..."
> 
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/