| To: | Lachlan McIlroy <lmcilroy@xxxxxxxxxx> |
|---|---|
| Subject: | Re: 2.6.30 panic - xfs_fs_destroy_inode |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Tue, 23 Jun 2009 13:13:05 -0400 |
| Cc: | Patrick Schreurs <patrick@xxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, Tommy van Leeuwen <tommy@xxxxxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx> |
| In-reply-to: | <1587994907.388291245745033392.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <4A408316.2070903@xxxxxxxxxxxxxxxx> <1587994907.388291245745033392.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.18 (2008-05-17) |
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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: inconsistent lock state on 2.6.30?, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH] xfs: implement ->dirty_inode callout, Christoph Hellwig |
| Previous by Thread: | Re: 2.6.30 panic - xfs_fs_destroy_inode, Lachlan McIlroy |
| Next by Thread: | Re: 2.6.30 panic - xfs_fs_destroy_inode, Patrick Schreurs |
| Indexes: | [Date] [Thread] [Top] [All Lists] |