Re: Reiser4. BEST FILESYSTEM EVER.


On Fri, 6 Apr 2007 23:30:49 -0400, "Jan Harkes" <jaharkes@xxxxxxxxxx>
said:

Since you decide to publically respond to a private email, but not only
you did not 'discuss' anything I wrote and in fact cut out most of the
useful information in my reply I guess I will have to repeat my
observations.

You are a funny guy Jan.

Here you are, once again, cutting out my most useful information, ie,
the data I was discussing, while complaining that I cut out your most
useful information.

You know,... you cut out this bit:

-----------------------------------------------------------------

The following benchmarks are from

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

.-------------------------.
| 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)

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).

-----------------------------------------------------------------

And this bit:

Jan,... Here is another section, you conveniently cut out. Maybe you
should explain why you cut out this section? Was it embarrassing to you?
I mean, your statement is sort of correct,... but it shows a basic
misunderstanding of filesystems.

With compression there is a pretty high probability that one corrupted
byte or disk block will result in loss of a considerably larger amount
of data.

Bad blocks are NOT dealt with by the filesystem,... so your comment is
irrelevant, or just plain wrong.

If your filesystem is writing to bad blocks, then throw away your
operating system.

-----------------------------------------------------------------

It is true that I considered your "most useful information," an
irrelevant section, which is why it was cut out (ignored).

I did not see my doing this, any worse than you doing it. I did not
realize that you were be so impolite.

As to your email being private, I had thought I had joined a mailing
list. I had not idea your email was meant to be private and just
considered it like all the others.

Now you mention it, I wondered why the email did not automatically list
the mailing lists, as recipients, and I had to add them. If I had
realized this I may have added the mailing lists as recipients, anyway.
It would be like me to do such. However, you should understand that I am
new to mailing lists.


Do you really have to repeat the results in every email you sent?

Damn, I did it again. WHY DO YOU CARE?

Because I saw them the first time around. And although the performance
difference on those micro benchmarks seems quite impressive, I'm not
convinced.

So, likewise, I saw your comments (you know the ones you miss so much)
the first time around, as I was not convinced of their worth.

The benchmarks measure certain data. Its fine you do not read into them,
stuff that isn't there, like reliability, for example.

Look, its simple, I am (among other things) discussing these results, so
people need to see them.

However, you do not discuss, you just repeat, and repeat, and repeat.

I never said I wanted discussion, you just said I did.

You just repeat, and repeat, and repeat.

In reality, I quite appreciate reasonable discussion. But, I doubt I
will get much from you.

But for what reason. Do you want an actual discussion, or do you hate
the reiserfs developers so much that you want to antagonize any and all
other Linux file systems developers?

Why do you think I hate reiserfs developers? That is an insane claim.
Why would I hate reiser3 developers?
Why would I hate reiser4 developers?
Why would I even dislike them?

I think Hans Reiser is a genius. Is that what you mean by hate?

Answer this question. Why do YOU think I am antagonizing reiserfs
developers?

You must have a reason for stating what you have.

By the way, I have pulled the plug on my REISER4 system, a number of
times now, and it recovers without problem.

Very nice for you. I guess you have also not been hit by out of memory
conditions or failing partial writes. So I guess we can ignore the patch
that was just sent a day or two ago to the mailing list because you
succesfully pulled the plug, a number of times at that.

Why are you attacking me with sarcasm, when I have just stated a simple
fact?

I have set up a Reiser4 partition with gzip compression, here is the
difference in disk usage of a typical Debian installation on two 10GB
partitions, one with Reiser3 and the other with Reiser4.

debian:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 10490104 6379164 4110940 61% /3
/dev/sda7 9967960 2632488 7335472 27% /7
...
Partition 3 is Reiser3 -- uses 6.4 GB.
Partition 7 is Reiser4 -- uses 2.6 GB.

So Reiser4 uses 2.6 GB to store the (typical) data that it takes Reiser3
6.4 GB to store (note it would take ext2/3/4 some 7 GB to store the same
info).

Wow, consider me totally and completely, unimpressed.


Here is the part of my email that you seemed to totally ignore,

Yes, I ignored it,.... is that a crime?

You've just saved yourself $3.80, now go get yourself a latte.
(see. http://tomayko.com/weblog/2006/09/11/that-dilbert-cartoon)

Seriously, disk storage is getting less expensive all the time, you can
already buy a 250GB SATA drive for $70. Also, compression doesn't help
once you store already compressed data such as jpeg images, mp3 files,
or mpeg2/4/divx video files. Not only are the savings non-existant, but
we still end up with the disadvantage that corruption propagates to
multiple files because of the compression in the file system.

I believe that compression in REISER4 is just a wrapper for gzip or lzo.
So each file is compressed and your "corruption propagation" is just in
your imagination.

And if it doesn't propagate across multiple files, the compression can't
be all that good

It can be as good as gzipping every file, ie, pretty damn good.

since it can't benefit as much from similarity between
files. So if that is the case and you really want to save diskspace you
almost have to look at read-only compressed filesystems such as cramfs,
squashfs, zisofs, cloop and various other variants in combination with
a unionfs overlay to get read/write functionality.

But in the end everything is a tradeoff. You can save diskspace, but
increase the cost of corruption.

You deliberately ignored the fact that bad blocks are NOT dealt with by
the filesystem,... but by the operating system. Like I said: If your
filesystem is writing to bad blocks, then throw away your operating
system.

Use a better compression algorithm, but
that uses more CPU or which is visible in performance of the
application.

Not necessarily, just look at the bonnie++ tests. The tests show that
using compression (with todays hardware) leads to read speeds that are
some FOUR times the physical disk read rate,...

but you ignore this as you have some strange anti-REISER religion.

Think about it,... read speeds that are some FOUR times the physical
disk read rate,... impossible without the use of compression (or
something similar).

This can be offset by caching more, and being lazier with
writebacks, but that hurts on-disk consistency, creates more memory
pressure (more swapout/paging) and generally slows down other
applications that aren't actually accessing the disk. Having a fast
multi-core cpu and lots of memory helps a lot, but at some point what
tradeoff did we just make, we saved a couple of dollars not having to
buy a larger disk, but we spend considerably more on the more
expensive cpu and memory.


Wow, consider me STILL totally impressed by your AMAZING BIAS.
Would you like to tell me why you are SO BIASED against REISER4?

John.
--

johnrobertbanks@xxxxxxxxxxx

--
http://www.fastmail.fm - Choose from over 50 domains or use your own

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

Relevant Pages

  • Re: Reiser4. BEST FILESYSTEM EVER.
    ... I guess you have also not been hit by out of memory ... one with Reiser3 and the other with Reiser4. ... Seriously, disk storage is getting less expensive all the time, you can ... multiple files because of the compression in the file system. ...
    (Linux-Kernel)
  • Re: Low disc space
    ... Computer icon on the Desktop and select System Restore. ... especially if you do not store offline copies on disk. ... You will have a Local Settings folder for each User Profile. ... Enable drive level compression. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Reiser4. BEST FILESYSTEM EVER - Christer Weinigel
    ... Even reading up on the REISER4 filesystem would help. ... YOU OWE IT to the people on the linux-kernel mailing list, ... they are rolled, but rolling every 5 min the compression takes <20 seconds, so ... realized this I may have added the mailing lists as recipients, ...
    (Linux-Kernel)
  • Re: disk compression ?
    ... since the msdos days I no longer followed low level disk management so I was ... so the number of clusters in a disk equals the ... 1st highest level layer) the seamless and transparent file management, ... 3rd layer) (IF COMPRESSION IS SET ONLY) try to compress as much as possible ...
    (microsoft.public.windows.file_system)
  • Re: Compression reduces free space
    ... Where are you getting your fee disk space information from? ... In Windows XP most users looked at the figures in Windows Explorer. ... The outlook files are several data files that I created (e.g., ... After the compression was done, the amount of free space was ...
    (microsoft.public.windows.vista.file_management)
Loading