apparent filesystem-related hangs

[Wes Morgan]

On Sat, 21 Apr 2007, Kris Kennaway wrote:

> On Sat, Apr 21, 2007 at 10:51:10PM -0400, Wes Morgan wrote:
>> I have several filesystems built on top of a gconcat volume consisting of
>> 2 300gb and 1 500gb drive. The /usr partition constitutes the bulk of it.
>> The volume is sitting around 95% full, and twice I've had the system
>> become "hung" in what I believe are filesystem operations. It seems to
>> crop up when rtorrent tries to create files that would fill up the system,
>> but of course it doesn't actually reserve it until it is used. Any running
>> process remains responsive until it needs to access the disk.
>>
>> The system was running a fairly recent 6.2-stable, March 29, but I've
>> since updated to the most recent -stable.
>>
>> If anyone can give me some pointers as to how to tell exactly where these
>> processes are hanging, I can try to reproduce it... But it takes a while
>> to fsck the volume so I don't want to have to try too many things. If it's
>> not a known problem I can then submit a PR.
>
>
> DEBUG_LOCKS, DEBUG_VFS_LOCKS, INVARIANTS, INVARIANT_SUPPORT, then
> 'show lockedvnods' and 'alltrace' from ddb via the serial console when
> it hangs.

Ok, I was easily able to duplicate this twice. The second time was by 
accident, and rtorrent held the only locked vnode. Leaving top running in 
a terminal, I was able to lock up rtorrent and then purposely lock another 
process that was visible. Both locked in "nbufkv":

  1011 morganw       1  -4    0 73440K 20272K nbufkv   0:04  0.20% rtorrent
   996 morganw       1  -4    0  7592K  5084K nbufkv   0:00  0.00% pine

The full dumps from ddb can be found at 
http://volatile.chemikals.org/ddb.txt.gz.

If there is no additional information that would be useful for a PR, I 
can go ahead and create one.



-- 
This .signature sanitized for your protection