Re: reiser4 plugins

Nikita Danilov
2004-08-27T18:57:17Z

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.