linux-kernel - Re: Question about Reiser4

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]
Date:	Tue, 24 Apr 2007 17:12:02 -0700
From:	lkml777@...mail.org
To:	"Edward Shishkin" <edward@...esys.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Vladimir V. Saveliev" <vs@...esys.com>,
	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Alex Zarochentsev" <zam@...esys.com>,
	"Linux kernel mailing list" <linux-kernel@...r.kernel.org>,
	"Eric Hopper" <hopper@...ifarious.org>, "Lex Lyamin" <flx@....ru>,
	"William Heimbigner" <icxcnika@....tar.cc>,
	"Rik van Riel" <riel@...hat.com>, "Xu CanHao" <xucanhao@...il.com>
Subject: Re: Question about Reiser4

On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> <hopper@...ifarious.org> said:

> I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> benchmark showing that compressing long strings of 0s results in things
> taking up very little space and being very fast.

I think you are deliberately being stupid here.

You are claiming that REISER4's good speed results when using
compression actually has a simple explanation and THEREFORE all good
result for the filesystem, even those results that have nothing to do
with compression, are negated.

NOTHING COULD BE FURTHER FROM THE TRUTH.

Your conclusion is a total travesty of logic.

As I understand it, the default Reiser4 DOES NOT USE any compression at
all, not even tail compression, but saves space by eliminating block
alignment wastage (tail compression is an option).

So lets LOSE the statistics that involve compression. The results now
look like this:

.-------------------------.
| FILESYSTEM | TIME |DISK |
| TYPE       |(secs)|USAGE|
.-------------------------.
|REISER4     | 3462 | 692 |
|EXT2        | 4092 | 816 |
|JFS         | 4225 | 806 |
|EXT4        | 4408 | 816 |
|EXT3        | 4421 | 816 |
|XFS         | 4625 | 779 |
|REISER3     | 6178 | 793 |
|FAT32       |12342 | 988 |
|NTFS-3g     |10414 | 772 |
.-------------------------.

These results are still EXTREMELY GOOD for REISER4.

These results still say that Reiser4 is a truly remarkable filesystem,
as stated in:

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://m.domaindlx.com/LinuxHelp/fs-benchmarks.htm

So why do I see an anti-Reiser religion, in all that you people say.

You, concentrate on the fact that bonnie++'s use of files that are
mainly zeroes, will make the results using compression less good than
they are.

I can't see anywhere where this has been denied.

In fact the other set of statistics that you just ignore, states that in
more realistic situations, the compression speedup is slightly negative.

What is wrong here, is:

You say that the Bonnie++ tests using compression are subject to
interpretation. No argument here.
You ignore the tests that confirm your statement. You are clearly not
interested in the actual results or their interpretation.
You, by some incredibly twisted "logic" the state that Reiser4 is
therefore not good, even though it is clearly the best filesystem when
NOT using compression.

This of course is completely deceitful "logic".

That the speed advantage from compression would be small is clear from
the OTHER data that you ignore, namely:

.-------------------------------------------------.
|File         |Disk |Copy |Copy |Tar  |Unzip| Del |
|System       |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type         | (MB)| (1) | (2) |655MB|655MB| Gig |
.-------------------------------------------------.
|REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
|REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
|REISER4      | 692 | 148 |  55 |  67 |  25 |  56 |
|EXT4         | 816 | 174 |  70 |  74 |  42 |  50 |
.-------------------------------------------------.


> So, the speed increase with compression (on very compressible kernel sources) is slightly negative,
> 
> but the speed is still comparable to that of EXT4.
> 
> > On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
> > <hopper@...ifarious.org> said:
> >
> > > I know that this whole effort has been put in disarray by the
> > > prosecution of Hans Reiser, but I'm curious as to its status. Is
> > > Reiser4 going to be going into the Linus kernel anytime soon? Is there
> > > somewhere I should be looking to find this out without wasting bandwidth
> > > here?
> >
> > There was a thread the other day, that talked about Reiser4.
> >
> > It took a while but I have found it (actually two)
> >
> > http://lkml.org/lkml/2007/4/5/360
> > http://lkml.org/lkml/2007/4/9/4
> >
> > You may want to check them out.
> 
> I did.  That whole thread is some guy spouting off a ludicrous Bonnie++
> benchmark showing that compressing long strings of 0s results in things
> taking up very little space and being very fast.
> 
> Such things will produce lots of flames and no useful information
> whatsoever as is evinced by the half conspiracy theory, half truth the
> thread degenerated into in the second message you linked to.
> 
-- 
  
  lkml777@...mail.org

-- 
http://www.fastmail.fm - mmm... Fastmail...

-
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/