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.
> I will try that next time it happens.
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)
Michael Sinz ---- Worldgate Communications ---- msinz@xxxxxxxxx
A master's secrets are only as good as
the master's ability to explain them to others.