xfs
[Top] [All Lists]

Re: another problem with latest code drops

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: another problem with latest code drops
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 16 Oct 2008 18:20:19 +1100
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <48F6EF7F.4070008@xxxxxxx>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <48F6A19D.9080900@xxxxxxx> <20081016060247.GF25906@disturbed> <48F6EF7F.4070008@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Oct 16, 2008 at 05:38:39PM +1000, Lachlan McIlroy wrote:
> Dave Chinner wrote:
>> On Thu, Oct 16, 2008 at 12:06:21PM +1000, Lachlan McIlroy wrote:
>>> fsstress started reporting these errors
>>>
>>> fsstress: check_cwd failure
>>> fsstress: check_cwd failure
>>> fsstress: check_cwd failure
>>> fsstress: check_cwd failure
>>> fsstress: check_cwd failure
>>> ...
....
>> Ah, yes. A shutdown in a directory transaction. Have you applied the
>> fix to the directory block allocation transaction accounting that was one
>> of the last patches I posted?
> Yes, I checked that in yesterday and ran with it overnight.

OK.

>> If so, then there's some other problem in that code that we'll
>> need a reproducable test case to be able to find....
>
> I was running 8 copies of this command:
> fsstress -p 64 -n 10000000 -d /mnt/data/fsstress.$i
>
> I tried it again but this time the system ran out of memory
> and locked up hard.  I couldn't see why though - maybe a memory
> leak.

I just ran up the same load in a UML session. I'd say it's this
slab:

  2482   2481  99%    0.23K    146       17       584K xfs_btree_cur

which is showing a leak. It is slowly growing on my system
and dropping the caches doesn't reduce it's size. At least it's
a place to start looking - somewhere in the new btree code we
seem to be leaking a btree cursor....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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