Message-ID: <20070408012745.GH3508@csclub.uwaterloo.ca>
Date:	Sat, 7 Apr 2007 21:27:45 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	johnrobertbanks@...tmail.fm
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ignatich <ignatich@...il.com>,
	reiserfs-list@...esys.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: Reiser4. BEST FILESYSTEM EVER.

On Sat, Apr 07, 2007 at 05:44:57PM -0700, johnrobertbanks@...tmail.fm wrote:
> Lennart. Tell me again that these results from 
> 
> http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
> http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm

Hmm, copying kernel sources around.  Not that interesting.  How does it
handle mpeg2 files (the majority of my personal data files is on a
mythtv system).  So a few large files, with mostly linear access, and
the occational file deletion.  Compression would gain nothing.

> are not of interest to you. I still don't understand why you have your
> head in the sand.

Well I find it hard to get excited about new filesystems.  I had
sufficiently nasty data loses due to reiserfs 3 back in the early 2.4
kernel days, that I no longer get excited about new filesystems.  now I
want something I trust that hasn't destroyed any of my data.  I tried
XFS for a while, ut the early 2.6 kernels had some nasty bugs in XFS too
that made that pretty much unusable.  Now I just stick with ext3.  Screw
performance, give me something that works all the time.

> .-------------------------.
> | FILESYSTEM | TIME |DISK |
> | TYPE       |(secs)|USAGE|
> .-------------------------.
> |REISER4 lzo | 1938 | 278 |
> |REISER4 gzip| 2295 | 213 |
> |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 |
> .-------------------------.
> 
> 
> Column one measures the time taken to complete the bonnie++ benchmarking
> test (run with the parameters bonnie++ -n128:128k:0)

Time without cpu usage is not interesting.  If you can increase
filesystem speed by 10% by doubling cpu load, then I don't want the
increase.  It is all relative.  Wall clock time by itself just doesn't
contain enough data to be useful.

> Column two, Disk Usage: measures the amount of disk used to store 655MB
> of raw data (which was 3 different copies of the Linux kernel sources).

I remember disk compression from the DOS days.  Disk space is too cheap
to bother with that crap anymore.  I don't care if it can theoretically
turn idle cpu cycles into improved disk speed.  Sometimes I don't have
idle cpu cycles to waste on that.

> OR LOOK AT THE FULL RESULTS:
> 
> .-------------------------------------------------.
> |File         |Disk |Copy |Copy |Tar  |Unzip| Del |
> |System       |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
> |Type         | (MB)| (1) | (2) |655MB|655MB| Gig |
> .-------------------------------------------------.
> |REISER4 gzip | 213 | 148 |  68 |  83 |  48 |  70 |
> |REISER4 lzo  | 278 | 138 |  56 |  80 |  34 |  84 |
> |REISER4 tails| 673 | 148 |  63 |  78 |  33 |  65 |
> |REISER4      | 692 | 148 |  55 |  67 |  25 |  56 |
> |NTFS3g       | 772 |1333 |1426 | 585 | 767 | 194 |
> |NTFS         | 779 | 781 | 173 |   X |   X |   X |
> |REISER3      | 793 | 184 |  98 |  85 |  63 |  22 |
> |XFS          | 799 | 220 | 173 | 119 |  90 | 106 |
> |JFS          | 806 | 228 | 202 |  95 |  97 | 127 |
> |EXT4 extents | 806 | 162 |  55 |  69 |  36 |  32 |
> |EXT4 default | 816 | 174 |  70 |  74 |  42 |  50 |
> |EXT3         | 816 | 182 |  74 |  73 |  43 |  51 |
> |EXT2         | 816 | 201 |  82 |  73 |  39 |  67 |
> |FAT32        | 988 | 253 | 158 | 118 |  81 |  95 |
> .-------------------------------------------------.
> 
> 
> Each test was preformed 5 times and the average value recorded.
> Disk Usage: The amount of disk used to store the data (which was 3
> different copies of the Linux kernel sources).
> The raw data (without filesystem meta-data, block alignment wastage,
> etc) was 655MB.
> Copy 655MB (1): Copy the data over a partition boundary.
> Copy 655MB (2): Copy the data within a partition.
> Tar Gzip 655MB: Tar and Gzip the data.
> Unzip UnTar 655MB: UnGzip and UnTar the data.
> Del 2.5 Gig: Delete everything just written (about 2.5 Gig).
> 
> To get a feel for the performance increases that can be achieved by
> using compression, we look at the total time (in seconds) to run the
> test:

kernel sources are some of the most compressable data files around.  Try
with some interesting data instead, like something with larger files,
mostly binary, which isn't likely to compess very much.

> bonnie++ -n128:128k:0 (bonnie++ is Version 1.93c)
> 
> .-------------------.
> | FILESYSTEM | TIME |
> .-------------------.
> |REISER4 lzo |  1938|
> |REISER4 gzip|  2295|
> |REISER4     |  3462|
> |EXT4        |  4408|
> |EXT2        |  4092|
> |JFS         |  4225|
> |EXT3        |  4421|
> |XFS         |  4625|
> |REISER3     |  6178|
> |FAT32       | 12342|
> |NTFS-3g     |>10414|
> .-------------------.
> -- 

Well Reiser4 certainly looks impresive, but I still want to know what the
cpu load is like, what the repair tools are like, how well it handles
power failures in the middle of a write (I didn't like the way reiser3
would claim to have the filesystem back to a sane state, but the file
it had been in the middle of writing now contained garbage in many parts
of it, with no warning what so ever that this had taken place).

Performance looks impresive, but based on the history of reiser3 there
is a lot of historical damage to undo before I will even consider
testing it out.

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

Powered by blists - more mailing lists