[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f96157c40607270642p44c89597pcbb7d5685b47dae8@mail.gmail.com>
Date: Thu, 27 Jul 2006 13:42:23 +0000
From: "gmu 2k6" <gmu2006@...il.com>
To: "Horst H. von Brand" <vonbrand@....utfsm.cl>
Cc: "Luigi Genoni" <genoni@....it>, "Adrian Bunk" <bunk@...sta.de>,
andrea@...share.com, "J. Bruce Fields" <bfields@...ldses.org>,
"Hans Reiser" <reiser@...esys.com>,
"Nikita Danilov" <nikita@...sterfs.com>,
"Rene Rebe" <rene@...ctcode.de>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: the ' 'official' point of view' expressed by kernelnewbies.org regarding reiser4 inclusion
On 7/27/06, Horst H. von Brand <vonbrand@....utfsm.cl> wrote:
> Luigi Genoni <genoni@....it> wrote:
>
> [...]
>
> > Anyway you have a datum.
> > Some people need reiser4, period.
>
> Nope. Some people run kernels that include reiser4. That is all you can
> infer, and that I knew beforehand. They are at least 35, and that I'd have
> guessed in any case.
35.5 as I'm testing it here on my workstation and it seems to be
faster when you test some things involving many copies of large
multi-level sourcetree directories each 3 to 6GiB big in size.
2.6.18-rc2-mm1 with Reiser4 looks ok so far and I had no sync() OOPS
like the last time with one -mm revision.
speed tells us nothing about reliability of course, but compared to
ext3 with dir_index,sparse_super Reiser4 seems to handle "du -sh" and
"rm -r" much faster and without eating all of the CPU cycles as it
finishes quicker although Reiser4 was meant to be CPU-heavy compared
to ext*/reiserfs3.
-
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