Re: i/o stalls on 2.4.14-pre3 with ext3

[David Mansfield <david@cobite.com>]

> David Mansfield wrote:
> > 
> > I tried out 2.4.14-pre3 plus the ext3 patch from Andrew Morton and
> > encountered some strange I/O stalls.   I was doing a 'cvs tag' of my local
> > kernel-cvs repository, which generates a lot of read/write traffic in a
> > single process.
> 
> hmm..  Thanks - I'll do some metadata-intensive testing.
> 
> ext3's problem is that it is unable to react to VM pressure 
> for metadata (buffercache) pages.  Once upon a time it did
> do this, but we backed it out because it involved mauling
> core kernel code.  So at present we only react to VM pressure
> for data pages.
> 
> Now that metadata pages have a backing address_space, I think we
> can again allow ext3 to react to VM pressure against metadata.
> It'll take some more mauling, but it's good mauling ;)
> 
> Then again, maybe something got broken in the buffer writeout
> code or something.
> 
> Is this repeatable? 
> 
> 	while true
> 	do
> 		cvs tag foo
> 		cvs tag -d foo
> 	done
> 
> If so, can you run `top' in parallel, see if there's
> anything suspicious happening?
> 

Yes it's very repeatable.  In fact, running as above demonstrates it even
better here because all of the file data ends up in the cache.  So there
are no reads to confuse things.  Basically, to save space - it's the same,
with the writes degenerating from 5000 a second to a couple
hundred.  During this time (the stalls) no process is using any CPU time
and only 'cvs' is in D state, according to ps.

Here's another detail, running 'sync' takes about 20 to 30 seconds during
these stalls, and I *think* cvs issues a 'sync' when it finishes the tag,
because it stalls in an even more pronounced way exactly at the end of the
tag (or un-tag). 

David


-- 
/==============================\
| David Mansfield              |
| david@cobite.com             |
\==============================/