From: Keith Owens <kaos@sgi.com>
To: Michael Sinz <msinz@wgate.com>
Cc: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: Strange behavior on the 2.4.18 XFS tree? 
In-reply-to: Your message of "Thu, 16 May 2002 13:57:44 -0400."
             <3CE3F318.1080500@wgate.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 17 May 2002 10:16:30 +1000
Message-ID: <5939.1021594590@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 16 May 2002 13:57:44 -0400, 
Michael Sinz <msinz@wgate.com> wrote:
>Well, given the "transient" nature of the problem, I can not be sure it
>really "fixed" it but doing the sync did look like it helped - alot.
>
>I could not even do an "ls -l" of a directory during the "stall" period.
>My already running system monitors (one of which is xosview) showed no
>CPU usage (well, almost none) and almost no disk I/O (mostly 0)
>
>All of memory was used - something on the order of:  (but not exactly as
>this was run after the system unblocked)
>
>              total       used       free     shared    buffers     cached
>Mem:        577396     567464       9932          0          0     233460
>-/+ buffers/cache:     334004     243392
>Swap:      2048276       1964    2046312
>
>(Yes, mozilla was running and so was the find in the background)
>
>The find (or other major filesystem traversal) is what helps trigger this
>condition.  Where is the system hung if there is no disk I/O and no CPU
>used (unless the CPU usage is not being accounted for?)
>
>BTW - once I did sync things worked as expected (ls ran quickly, etc)

That is the same symptom I have seen.  Something has a lock and is not
moving, probably waiting on an event.  Forcing some disk flush activity
causes enough events to get everything going again.