Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser. Is there any idea to incorporate it in Test 3 considering the freeze in test 2 ?
Regards, Manu
On Thu, Sep 16, 2004 at 09:33:39PM +0400, Manu Abraham wrote:
Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser. Is there any idea to incorporate it in Test 3 considering the freeze in test 2 ?
None. Fedora tries to closely track the base kernel so until the base kernel gets reiser4 it is unlikely FC will
On Thu, 2004-09-16 at 21:33 +0400, Manu Abraham wrote:
Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser.
Just out of curiosity, why would you want reiser4 in FC3?
It's not ready. It's unclear as to whether its concepts are even a good idea, despite the Namesys marketing propaganda.
-Steve Bergman
On Sat September 18 2004 2:07 am, Steve Bergman wrote:
On Thu, 2004-09-16 at 21:33 +0400, Manu Abraham wrote:
Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser.
Just out of curiosity, why would you want reiser4 in FC3?
Reiser4 sounds cool, that's why.
It's not ready. It's unclear as to whether its concepts are even a good idea, despite the Namesys marketing propaganda.
what makes one think so ?
Manu
-Steve Bergman
Le sam 18/09/2004 à 18:03, Manu Abraham a écrit :
On Sat September 18 2004 2:07 am, Steve Bergman wrote:
On Thu, 2004-09-16 at 21:33 +0400, Manu Abraham wrote:
Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser.
Just out of curiosity, why would you want reiser4 in FC3?
Reiser4 sounds cool, that's why.
It's not ready. It's unclear as to whether its concepts are even a good idea, despite the Namesys marketing propaganda.
what makes one think so ?
http://lwn.net/Articles/99232/ http://lwn.net/Articles/100148/
Manu
-Steve Bergman
On Sun September 19 2004 2:19 am, Matias Feliciano wrote:
Le sam 18/09/2004 à 18:03, Manu Abraham a écrit :
On Sat September 18 2004 2:07 am, Steve Bergman wrote:
On Thu, 2004-09-16 at 21:33 +0400, Manu Abraham wrote:
Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser.
Just out of curiosity, why would you want reiser4 in FC3?
Reiser4 sounds cool, that's why.
It's not ready. It's unclear as to whether its concepts are even a good idea, despite the Namesys marketing propaganda.
what makes one think so ?
http://lwn.net/Articles/99232/ http://lwn.net/Articles/100148/
I didn't know so many issues existed. I was aware of only about the 4k stack and the file/directory concept.
Thanks for the info. I think then reiser4 should take the natural path.
Manu
Manu
-Steve Bergman
I have taken a quick look at the first article and I have a BIG problem with the benchmark part.
First of all it looks like the guy divided his 4GB disk in two 2G partitions and installed Reiser on one partition and EXT3 in the other. WRONG! Modern disks have more sectors in the outer, lower numbered tracks. Meaning that you will get higher throughput from hda1 than from hda2.
Second. I hope he stopped all daemons and performed his tests in single mode.
He also compiled the kernel as a benchmark. 99% of times this is the touchstone for lack of proper thinking in benchmarking. Compiling a kernel is a terrible benchmark for a filesystem: first, because even on a machine with a 2000+ Athlon over 50% of the time will be spent crunching gcc code, the rest is kernel time (a good part of it not being FS related), and waiting for I/O (that is FS-related) so we can guess only about 25 or 30% of total time is influenced by FS, and you get "noise" from the other 70%. But on slower boxes like the one he used the relation from CPU (ie mostly gcc) to total time will be still higher
But that is the not the sole reason why compiling a kernel is a poor benchmark: kernel source is a bunch of small files packed into moderately sized directories and its compiling it is only about _sequential_ access. What about the performance on huge files? What about direct access like needed for databases? What about huge directories? Compiling the kernel will teach you nothing about these. Same thing for grepping through the source code (but at least there is lesser user-mode cpu time)
In addition a filesystem could be better at reading than at writing, when partition is nearly empty or when nearly full, when partition has been recently formatted or when it has had lots of insertions and deletions. Where are the tests for measuring those aspects of performance?
Making a real benchmark involves ensuring that no external factors come to distort the resullts (eg using the same partition for both filesystems), that the tests are significative (ie they spent 90% of the time exerting what we are trying to measure) and that all important factors of performance are measured and withted for final evaluation
Le dim 19/09/2004 à 00:19, Matias Feliciano a écrit :
Le sam 18/09/2004 à 18:03, Manu Abraham a écrit :
On Sat September 18 2004 2:07 am, Steve Bergman wrote:
On Thu, 2004-09-16 at 21:33 +0400, Manu Abraham wrote:
Hi, Reiser4 has been officially released and considered stable by Mr. Hans Reiser.
Just out of curiosity, why would you want reiser4 in FC3?
Reiser4 sounds cool, that's why.
It's not ready. It's unclear as to whether its concepts are even a good idea, despite the Namesys marketing propaganda.
what makes one think so ?
http://lwn.net/Articles/99232/ http://lwn.net/Articles/100148/
Manu
-Steve Bergman
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Jean Francois Martinez jfm512@free.fr wrote:
First of all it looks like the guy divided his 4GB disk in two 2G partitions and installed Reiser on one partition and EXT3 in the other. WRONG! Modern disks have more sectors in the outer, lower numbered tracks. Meaning that you will get higher throughput from hda1 than from hda2.
Wrong indeed. The same partition was used for all tests. One can give me a little credit, even if it hurts.
He also compiled the kernel as a benchmark. 99% of times this is the touchstone for lack of proper thinking in benchmarking.
Because I benchmarked an actual task that my readers are likely to perform?
Look, the benchmarks in the LWN articles were a low-value exercise, just to get a rough feel for the performance benefits claimed by reiser4. I believe I succeeded in that goal. Among other things, I turned up the fact that, if you fail to create your files in the right order, performance suffers significantly - something which the Namesys marketing literature somehow failed to mention.
jon
Jonathan Corbet Executive editor, LWN.net corbet@lwn.net
Hello Jonathan,
On Mon, 2004-09-20 at 16:31, Jonathan Corbet wrote:
He also compiled the kernel as a benchmark. 99% of times this is the touchstone for lack of proper thinking in benchmarking.
Because I benchmarked an actual task that my readers are likely to perform?
No, because if you benchmark a file system you shouldn't benchmark a CPU intensive task like compiling a kernel as file system performance will only have a relatively small impact on the compilation time (signal/noise). That sounds like valid criticism to me.
Leonard.
On Mon, Sep 20, 2004 at 06:16:35PM +0200, Leonard den Ottolander wrote:
Hello Jonathan,
On Mon, 2004-09-20 at 16:31, Jonathan Corbet wrote:
He also compiled the kernel as a benchmark. 99% of times this is the touchstone for lack of proper thinking in benchmarking.
Because I benchmarked an actual task that my readers are likely to perform?
No, because if you benchmark a file system you shouldn't benchmark a CPU intensive task like compiling a kernel as file system performance will only have a relatively small impact on the compilation time (signal/noise). That sounds like valid criticism to me.
He wasn't benchmarking the machines, he was benchmarking the file systems.
All else being equal, a usual operation as a fs benchmark is a valid one.
A simple, idiotic test like flipping 0s and 1s in ram would still be a valid test, though with much less significance. If a simple memtest resulted if so very different results if under different filesystems, then something would be very wrong with one of them.
Regards, Luciano Rocha
PS: A compilation can be very dependent on file system performance. Not usually as much as the processor, of course, but stil...
Leonard den Ottolander leonard@den.ottolander.nl wrote:
Because I benchmarked an actual task that my readers are likely to perform?
No, because if you benchmark a file system you shouldn't benchmark a CPU intensive task like compiling a kernel as file system performance will only have a relatively small impact on the compilation time (signal/noise).
A change from 1400 seconds (ext3) to 1583 (reiser4) strikes me as more than noise. If I run reiser4 on that particular system, I have to wait three more minutes to get my kernel built. (Yes, it drops to 1445 seconds if you happen to have a kernel tarball built in the reiser4-optimum order, but that is worth noting too).
Reiser4 is a CPU-heavy filesystem - by admission of its own developers. So its performance will certainly suffer, relative to lighter filesystems, when executing a CPU-intensive, filesystem-intensive task. Running benchmarks which do not load the processor can be useful for generating those "guaranteed not to exceed" numbers, but they mask the extra cost involved in using a filesystem which requires a lot of processor time to operate.
If I wanted to print best-case-scenario benchmarks, I could have simply copied them from Namesys.com. I think there is also a place for "real world" tests.
jon
Hi Jon,
On Mon, 2004-09-20 at 19:28, Jonathan Corbet wrote:
A change from 1400 seconds (ext3) to 1583 (reiser4) strikes me as more than noise.
I didn't state the results are just noise, just that when testing the file system specifically doing this with a CPU intensive task the signal/noise ratio will suffer.
However
Reiser4 is a CPU-heavy filesystem - by admission of its own developers. So its performance will certainly suffer, relative to lighter filesystems, when executing a CPU-intensive, filesystem-intensive task.
I hadn't considered reiser4 is much more CPU intensive than ext3, which indeed makes the distinction between CPU and fs intensive less clear, and speaks for your approach. That's the trouble with benchmarking, you have to know what you want to test. And it's important to make such considerations explicit when publishing results.
Leonard.
On Mon, Sep 20, 2004 at 09:19:10PM +0200, Leonard den Ottolander spake thusly:
I hadn't considered reiser4 is much more CPU intensive than ext3, which indeed makes the distinction between CPU and fs intensive less clear,
As long as CPU is so much more faster than disk I think Hans is taking the right approach.
Le lun 20/09/2004 à 16:31, Jonathan Corbet a écrit :
Jean Francois Martinez jfm512@free.fr wrote:
First of all it looks like the guy divided his 4GB disk in two 2G partitions and installed Reiser on one partition and EXT3 in the other. WRONG! Modern disks have more sectors in the outer, lower numbered tracks. Meaning that you will get higher throughput from hda1 than from hda2.
Wrong indeed. The same partition was used for all tests. One can give me a little credit, even if it hurts.
Sorry, when I saw you used a 2G partition on a 4G disk I thought you had cut in two halves, one for Reiser, the other one for EXT3.
He also compiled the kernel as a benchmark. 99% of times this is the touchstone for lack of proper thinking in benchmarking.
Because I benchmarked an actual task that my readers are likely to perform?
The other day I had a discussion with the sysadmin of another department and our common position was: 1) The state of the art in kernel building (ie use of modules and cpu detection by the installer) allows vendors to ship kernels whose performance is close enough to a custom built one the user should not need to bother with recompiling. 2) If the kernel you get out of the box is an underperformer then it is a _bug_. And we both refuse to fix the bad work of a vendor: if he doesn't fix the bug then he is out. So here you have two persons who administer several Linux and Unix boxes who never compile kernels but who run databases (both free and proprietary).
Look, the benchmarks in the LWN articles were a low-value exercise, just to get a rough feel for the performance benefits claimed by reiser4. I believe I succeeded in that goal. Among other things, I turned up the fact that, if you fail to create your files in the right order, performance suffers significantly - something which the Namesys marketing literature somehow failed to mention.
That is good.
Now forgive me a former statistician who tends to be pedantic (and harsh) about benchmarks.
jon
Jonathan Corbet Executive editor, LWN.net corbet@lwn.net
On Mon, 2004-09-20 at 23:12 +0200, Jean Francois Martinez wrote:
The other day I had a discussion with the sysadmin of another department and our common position was: 1) The state of the art in kernel building (ie use of modules and cpu detection by the installer) allows vendors to ship kernels whose performance is close enough to a custom built one the user should not need to bother with recompiling. 2) If the kernel you get out of the box is an underperformer then it is a _bug_.
Er, a large part of the LWN audience is kernel and other low-level systems developers. This may seem surprising, but kernel developers tend to compile their own kernels, and then install them.
On Tue, 2004-09-21 at 04:16, Colin Walters wrote:
On Mon, 2004-09-20 at 23:12 +0200, Jean Francois Martinez wrote:
The other day I had a discussion with the sysadmin of another department and our common position was: 1) The state of the art in kernel building (ie use of modules and cpu detection by the installer) allows vendors to ship kernels whose performance is close enough to a custom built one the user should not need to bother with recompiling. 2) If the kernel you get out of the box is an underperformer then it is a _bug_.
Er, a large part of the LWN audience is kernel and other low-level systems developers. This may seem surprising, but kernel developers tend to compile their own kernels, and then install them.
If kernel developers were a _large_ part of LWN's audience then LWN would have died long ago due to lack of revenue. Oh and a still larger portion uses a web browser...
I persist that a proper benchmark should between other things 1) be strongly coupled with what you are trying to measure 2) Try to cover a reasonably large part of the different aspects of performance. It is to the user, not to the author to select the aspects who are important to him and if for some reason you make a limited test then you should include some caveats like "kernel compiling is mostly about reading small files in small or average directories, it doesn't exert this, this and this"
And now if you want to discuss it further I think we should do it in private
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Le mar 21/09/2004 à 21:01, Jean Francois Martinez a écrit :
I persist that a proper benchmark should
OK, prefer reiser4 since it's the best FS for _your_ benchmarks. LWN write very good/interesting articles even with bias benchmarks (which i don't really care for file system).
On Tue, Sep 21, 2004 at 11:55:36PM +0200, Matias Feliciano wrote:
OK, prefer reiser4 since it's the best FS for _your_ benchmarks. LWN write very good/interesting articles even with bias benchmarks (which i don't really care for file system).
The LWN benchmark implies the disk was partitioned and each fs got one of the two 2G partitions if so then its worthless because there is often over 20% speed difference between different parts of a disk
On Tue, 2004-09-21 at 15:00, Alan Cox wrote:
The LWN benchmark implies the disk was partitioned and each fs got one of the two 2G partitions if so then its worthless because there is often over 20% speed difference between different parts of a disk
However, earlier in this thread Jonathan Corbet explained that he actually used _the same partition_ for testing both filesystems; in this case, the fact that there were more partitions on the disk is a completely irrelevant implementation detail which could in fact just as well have been left out of the article. So it seems that the benchmark was OK but the explanation in the article might have been a bit confusing.
/Per
On Sun, Sep 19, 2004 at 12:19:51AM +0200, Matias Feliciano spake thusly:
Le sam 18/09/2004 à 18:03, Manu Abraham a écrit :
On Sat September 18 2004 2:07 am, Steve Bergman wrote:
On Thu, 2004-09-16 at 21:33 +0400, Manu Abraham wrote:
Reiser4 has been officially released and considered stable by Mr. Hans
Just out of curiosity, why would you want reiser4 in FC3?
Reiser4 sounds cool, that's why.
It's not ready. It's unclear as to whether its concepts are even a good idea, despite the Namesys marketing propaganda.
what makes one think so ?
I really look forward to being able to user reiser4 with FC. It would make sense for FC to prefer reiser4 over reiser3 because SE Linux will work on reiser4 due to its support of xattrs.
And in general I see reiser4 being the Linux answer to WinFS and all that other stuff MS has been promising us for years and years. Surely ext3 isn't the end of evolution in filesystems. I look forward to filesystems becoming more flexible and more like general purpose databases which can be extended in a modular fashion with plugins and reiser4 seems to fit that bill.
On Wed, 22 Sep 2004 11:04, Tracy R Reed treed@ultraviolet.org wrote:
I really look forward to being able to user reiser4 with FC. It would make sense for FC to prefer reiser4 over reiser3 because SE Linux will work on reiser4 due to its support of xattrs.
I'll believe that when I see it.
There is Reiser3 XATTR code and SE Linux hooks, but they don't work.
Also Reiser4 apparently (according to the LWN articles referenced before) needs a new system call. LSM and SE Linux used to have a system call, the main kernel coders didn't like it and it was re-written to not use a system call.
Don't expect Reiser4 with an extra system-call to get into the kernel any time soon. It won't be in Fedora as long as it's not in kernel.org.