[Top] [All Lists]

Re: XFS stack overflow?

To: simon@xxxxxxxxxxxxxxxxx
Subject: Re: XFS stack overflow?
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 31 Mar 2011 10:37:10 -0400
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1301581135.748149.10230.nullmailer@xxxxxxxxxxxxxxxxx>
References: <1301581135.748149.10230.nullmailer@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Mar 31, 2011 at 03:18:55PM +0100, simon@xxxxxxxxxxxxxxxxx wrote:
> x86_64
> Storage is fibrechannel attached and the filesystem is hosted on a 
> LVM block device that concatentates four partitions, so the block access
> is going via a stack of LVM, multipath and Q-logic drivers.
> Network is Intel 10G ethernet (gxbe driver)
> Kernel is 2.6.32 with Debian patches. (both kernels)

Yes, this very much looks like a stack overflow caused by direct
reclaim from a context with a lot of stack usage into a filesystem (XFS
in this case) with a deep storage stack underneath.

The fix for this is to disable direct reclaim, which the VM maintainers
refuse.  We finally gave in and added a hack similar to the other
modern filesystems to prevent this from inside XFS.

Try backporting commits:

        "xfs: skip writeback from reclaim context"


        "xfs: allow writeback from kswapd"

from current mainline to avoid these kinds of issues.

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