Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Sep 2001 14:07:16 -0700
From:      David Greenman <dg@root.com>
To:        Mike Barcroft <mike@FreeBSD.org>
Cc:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/19479: processes stuck in 'ffsvgt' and 'FFS no' states
Message-ID:  <20010922140716.B28469@nexus.root.com>
In-Reply-To: <20010922135045.A28469@nexus.root.com>; from dg@root.com on Sat, Sep 22, 2001 at 01:50:45PM -0700
References:  <200109220310.f8M3A2570482@freefall.freebsd.org> <20010922135045.A28469@nexus.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>>      FFS node204489102245K 102245K102400K   663650    0     0  512
>> <deadlock here!>
>> 
>> 102245K seems like an awful lot of memory for FFS nodes?
>> what would cause this?   does anyone else see very large FFS node
>...
>> clearly we are reaching the malloc limit for "FFS node" and hanging.
>
>   Yes, and it is easy to reproduce. Just read/write a lot of files (a few
>hundred thousand) on a machine with a lot of memory (1GB or more). The
>problem is caused by FreeBSD's overly agressive desire to keep vnodes (and
>their attached FS nodes) around in order to be able to cache the associated
>file data. I haven't looked at the problem in great detail (I would have a
>fix for this if I had), but basically there needs to be a cap on how many
>vnodes are allowed to stick around after all the references have been dropped
>and vnodes with no cached pages should be freed immediately. There used to
>be such a cap, but someone removed it a long time ago.

   Looks like there is another contributor to this, as pointed out by
Matt Dillon, the namei cache is part of the problem as well. The algorithm
tries to hang on to the vnode so that the namei cache entries don't become
useless (they point to vnodes, so if the vnode is recycled then the namei
cache entry becomes useless).
   All of this code is tricky with complex relationships and interactions.
It's not going to be trivial to come up with a good fix that doesn't also
sacrifice performance one way or another.

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010922140716.B28469>