[Top] [All Lists]

Re: 2.6.30 panic - xfs_fs_destroy_inode

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: 2.6.30 panic - xfs_fs_destroy_inode
From: Patrick Schreurs <patrick@xxxxxxxxxxxxxxxx>
Date: Tue, 30 Jun 2009 22:13:57 +0200
Cc: Lachlan McIlroy <lmcilroy@xxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, Tommy van Leeuwen <tommy@xxxxxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>
In-reply-to: <20090623171305.GB23971@xxxxxxxxxxxxx>
Organization: News-Service.com
References: <4A408316.2070903@xxxxxxxxxxxxxxxx> <1587994907.388291245745033392.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090623171305.GB23971@xxxxxxxxxxxxx>
User-agent: Thunderbird (Windows/20090605)
Hi (again),

Anyone has any advice to prevent this from happening? We've seen 10 crashes in the last 14 days. Would it be helpful to enable CONFIG_XFS_DEBUG? Does this result in a big performance hit on busy xfs filesystems? If we can help troubleshoot this problem, please advice.

If i understand correctly this issue also exists in 2.6.29? Should i downgrade to the latest 2.6.28 kernel to regain stability?



Christoph Hellwig wrote:
On Tue, Jun 23, 2009 at 04:17:13AM -0400, Lachlan McIlroy wrote:
It looks to me like xfs_reclaim_inode() has returned EAGAIN because the
XFS_RECLAIM flag was set on the xfs inode.  This implies we are trying
to reclaim an inode that is already in the process of being reclaimed.
I'm not sure how this happened but it could be a simple case of ignoring
this error since the reclaim is already in progress.

Well, having the reclaim already in progress means we're racing here.
And I suspect this fits into the other bugs with possibly duplicat
inodes we see after the inode+xfs_inode unification.

xfs mailing list

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