[lkml]   [2004]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: reiser4 plugins
Nikita Danilov wrote:

> > >Whoever sponsors the benchmark usually wins. Had you forgotten that
> > >mongo setup used by was specially
> > >`tuned' to reach peak reiser4 performance? Remember why you decided to
> > >turn OVERWRITE and MODIFY phases off?
What I should have done was what I did with fsync performance. With
fsync performance I told people that we had not yet tuned for it, please
wait a bit and we will tune for it, for now it sucks.

Instead what I did was discuss with Zam at the time how it could be
fixed, leave it off the website until Zam was given a chance to fix it,
and then I managed to forget about it. After release one remembers
what all the things that should have been fixed before release were, sigh.

Zam and I both know what is needed to fix performance in these phases,
and I just spoke with him on the phone. I imagine it is 2 weeks of work
for him, but it could be up to 6 weeks. He will comment later.

The fix should consist of the following:

1) tweak the relocation policies (zam will say more about this, as he is
the maintainer of them)

2) optimize overwrite set so that in the modify phase we behave like a
write twice journaling filesystem, which means implement a reserved for
the journal only area that exists as long as plenty of disk space is free.

3) finish the repacker (but we won't do that this month....)

The modify phase, which picks a random block to modify, is a worst case
for a wandering log without a repacker. We could actually do very very
well at that kind of activity with a repacker, probably better than a
fixed journal, but for now we should try acting like a write twice
journal for atoms that small.

So, having realized my error thanks to the gracious kindness of how you
pointed it out, we will modify the web site to say that we are not yet
tuned for and currently suck at modifying random blocks in the middle of
files, and appending small amounts to the end of them, and overwriting
small files, but that we think we know what is needed to fix those things.

I think your characterization of my reasons was unkind and also unfair.
I will pass on saying similarly unkind things about you as you are
mostly a good person. You never did seem to understand me. You didn't
understand the reasons for my technical designs (when they worked it
made no sense to you that they did), and you didn't understand me as a

I wish you well in your new job, and thank you for the hard work you did
for me.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.584 / U:3.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site