"Vladimir V. Saveliev" wrote:
>
> Dirk Haage wrote:
>
> > Am 03 Jul 2001 21:18:34 +0400 schrieb Nikita Danilov:
> > [some performance tests]
> > > [Table skipped.]
> > >
> > > ReiserFS is extremely fast with simple file system operations; as soon as
>parallel
> > > accesses of several processes takes place, the performance breaks in
> > > however clearly.
> >
> > So the real question ist, why does ReiserFS-Performance drop if parallel accesses
> > happen? Is there any explanation for this?
> >
>
> Probably due to "an algorithm" of repeats reiserfs uses to perform parallel tree
> updates. The more parallel acccess work together - the more they have to repeat - the
> more performance falls down.
>
> Thanks,
> vs
More likely, reiserfs schedules more often than ext2 (during accesses to formatted
nodes), and
scheduling reduces serialization, and greater serialization improves parallel accesses
on a single
disk drive (by huge amounts, as you can see if you run a few benchmarks).
The parallel updates explanation seems unlikely to me, because find + wc does not
cause balancing.
Reading indirect items is expensive, because we do no readahead on them, and as a
result other IOs
have an opportunity to insert themselves and move the head away.
We need not just to have indirect items that precede the blocks that they point to,
but also to keep
other things from grabbing our disk head while we wait for the indirect item to tell
us to read the
block immediately after it.
Perhaps giving Linux a real elevator algorithm, plus doing readahead when accessing
indirect items
that are located right after the block just read?
Thoughts on how we might solve this?
Hans
