Messages in this thread | | | From | Nikita Danilov <> | Date | Fri, 27 Aug 2004 22:55:50 +0400 | Subject | Re: reiser4 plugins |
| |
Hans Reiser writes: > Nikita Danilov wrote: > > >Hans Reiser writes: > > > Christophe Saout wrote: > > > > > > > > > > > > > > >I don't know, ask Hans. How could the VFS know it a filesystem wants to > > > >do something specific with a file that is completely transparent to the > > > >VFS? > > > > > > > > > > > > > > > To know what method to use, you must determine the pluginid, and then > > > find the method within that plugin for that vfs operation. > > > > > > As for overhead, well, who eats whose dust in the benchmarks....? > > > >Whoever sponsors the benchmark usually wins. Had you forgotten that > >mongo setup used by http://www.namesys.com/benchmarks.html was specially > >`tuned' to reach peak reiser4 performance? Remember why you decided to > >turn OVERWRITE and MODIFY phases off? People on #reiser4 report 90 > >_second_ stalls with reiser4 under high io loads (large atom is > >obviously being flushed and everyone waits on it...). In my opinion, it > >is such things that are of utmost importance for real reiser4 > >acceptance, not how to name `metas' sub-directory. > > > >Nikita. > > > > > > > > > If you ask real users, they say that reiser4 is fast, and their > experience matches our benchmark. You can criticize the benchmark if
They experience 90 second stalls. And please, do not tell me how fast reiser4 is, I spent a lot of time working with it, and I know very well when it's fast, and when it's deadly slow.
> you want, but then you should run your own and publish it.
I did, after which you told me to turn OVERWRITE and MODIFY phases off, beause performance was horrible.
I not criticizing mongo benchmark per se. I think that it is fundamentally wrong to use results that were deliberatly manipulated to get best appearance to reiser4 (by omitting work-loads where it performs poorly) as an argument. It's not clear who will, according to your colorful expression, `eat dust' as a result of this. Or do you think that users never overwrite of modify files in real life?
> The 90 second stalls, those should be fixed by debugging copy on capture > and turning it on, yes? You can hardly claim I failed to push for the
No. I described so many times to you, why COC is ineffectual here.
> Hans
Nikita. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |