On Wed, Sep 08, 2004 at 09:51:26AM -0500, Eric Sandeen wrote:
> >How well known this problem is, I don't know - I can get more details on
> >this if anyone is actually interested in working on fixing XFS.
> Do you have -any- details on this problem... pretty much nothing to go
> on here.
Yes, definitely! Thank you for the response!
I'll make sure the details are sent to this list ASAP.
> >Third XFS bug:
> >XFS causes lowmem oom, triggering the OOM killer. Reported by
> >as@xxxxxxxxxxxx on the 18th of august.
> >On the 24th of august, William Lee Irwin gives some suggestions and
> >mentions "xfs has some known bad slab behavior."
> I'm curious to know what that means... :)
Me too ;)
> >So, it's normal to OOM the lowmem with XFS? Again, more info can be
> >presented if anyone cares about fixing this.
> of course, please file a bug with all info you have. How do you know
> it's xfs causing the oom killer to kick in? Surely there are other
> memory consumers on the box; also how much memory is in the box to start
/proc/slabinfo reveals that it is XFS filling up the slab (which is in
Monitoring graphs show that the slab grows violently shorly before the
Will get this info to you as well...
> This may have as much to do with the way linux (2.4, anyway) caches
> dentries; xfs has structures that can't be freed as long as the dentry
> still has a reference.
Both systems are on 184.108.40.206
> Yes, sgi is maintaining it. Perhaps you've missed the large volume of
> commits on the linux-xfs list and on lkml. :)
I've seen plenty of commits. But I was baffled, to put it mildly, to
find that a patch which solves a problem that has been well known for
half a year (and is trivially triggered), has not yet been merged in the
mainline kernels. This is simply why I was wondering...
Thanks a lot for replying! I'll get the info too this list right away.