Re: reiserfs blocks long on getdents64() during concurrent write

Roland Kuhn
2002-08-06T09:58:18Z

On 5 Aug 2002, Chris Mason wrote:

> On Mon, 2002-08-05 at 18:46, Roland Kuhn wrote:
> >
> > But more important: the hiccups are more seldom and sometimes shorter than
> > before. With plain 2.4.19 I would hit it about twice per minute (I have
> > not measured it), now it happens only after two minutes when writing 1M
> > chunks at 20MB/s. The longest seen so far was also about 4 seconds,
> > though.
>
> This is harder to guess at ;-) But I'll try 2 things I know I've fixed.
>
> #1 I've made the metadata writeback code much more efficient, especially
> for smaller transactions. A dd to a large file won't generate lots of
> log traffic, writing 700M only changes about 160 blocks in 30 seconds.
> Anyway, 03-data-logging-24 might make a big difference.
>
It is hard to get precise numbers, but I have the feeling that with atime
enabled the ls-hiccups have at least not decreased, and there has been a
rather long one of about 13 seconds, frequency is about one per minute,
usually taking 2-4 seconds.

With noatime this of course doesn't happen, but with the patch the file
size does not increase smoothly any more, it sometimes stays the same for
some ten seconds and then jumps a few hundred MBs. However, the throughput
is roughly the same as without the patch (compatible within the errors of
about 10%).

> #2 During an ls, the current code ends up reading the directory more or
> less one block at a time. Try 05-search_reada-4.diff, which will read
> more tree nodes at once.
>
Unfortunately I'm ordered to do something now, so I won't have the time to
check the performance of this one during the next few hours. The
combination of 01+02+04 seemed more stable (concerning sustained
throughput), so I will test it on all 12 machines and tell you what
happens.

Thanks very much for your help! I appreciate that!