[Top] [All Lists]

Re: Strange behavior on the 2.4.18 XFS tree?

To: Steve Lord <lord@xxxxxxx>
Subject: Re: Strange behavior on the 2.4.18 XFS tree?
From: Michael Sinz <msinz@xxxxxxxxx>
Date: Thu, 30 May 2002 10:53:47 -0400
Cc: Keith Owens <kaos@xxxxxxx>, linux-xfs@xxxxxxxxxxx
References: <22203.1021466116@xxxxxxxxxxxxxxxxxxxxx> <3CE8ED3B.2090401@xxxxxxxxx> <1021916328.26650.251.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020524
Steve Lord wrote:
On Mon, 2002-05-20 at 07:34, Michael Sinz wrote:

Keith Owens wrote:

On Wed, 15 May 2002 07:30:09 -0400, Michael Sinz <msinz@xxxxxxxxx> wrote:

I have only been able to see this behavior on my system running the
kernel from the 2.4 XFS CVS tree.  It is somewhat reproduceable.

The problem is that I started up a number of "rxvt" sessions and they
took well over a minute to start up.  During that time, the cpu
utilization was almost nil.  (Less than 1%)

There was a background find operation happening, and this seems to be
the key item.

When the problem occurs, does typing sync get everything running again?
I have been seeing an intermittent lock problem with XFS where
everything stops until some other disk activity kicks in and the lock
is released.

A build of 2.4.18-XFS from CVS on Friday night seems to not show the
problem.  At least not over the last 2+ days.

It could also be that I did not run into it either.  Just providing
some more information as it develops :-)

Keep an eye on this problem, the code changes which went in for the
multiple blocksize support will affect when we sync data to disk. I think could well have a positive effect on what ever is happening
to you.

Well, I have not seen the problem since the latest CVS changes (as
stated above) and have really been trying to push the system hard (such
as doing multiple parallel compiles of various Mozilla code trees
and kernel builds and builds of our tools)

I am sure you are not "happy" with the fact that the problem has gone
away without directly addressing it but as far as I can see, the behavior
is no longer there.

BTW - I am hoping to soon (few weeks?) be doing some really large
cluster loading with this kernel.  We are getting closer to having
all of our code running on the Linux platform - its all the little
details that just suck up the time :-(...

Michael Sinz ---- Worldgate Communications ---- msinz@xxxxxxxxx
A master's secrets are only as good as
        the master's ability to explain them to others.

<Prev in Thread] Current Thread [Next in Thread>