| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 01/12] repair: do not walk the unlinked inode list |
| From: | Mark Tinguely <tinguely@xxxxxxx> |
| Date: | Thu, 12 Jan 2012 13:30:06 -0600 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20111202174741.091561992@xxxxxxxxxxxxxxxxxxxxxx> |
| References: | <20111202174619.179530033@xxxxxxxxxxxxxxxxxxxxxx> <20111202174741.091561992@xxxxxxxxxxxxxxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20111206 Thunderbird/3.1.16 |
On 01/-10/63 13:59, Christoph Hellwig wrote: Stefan Pfetzing reported a bug where xfs_repair got stuck eating 100% CPU in phase3. We track it down to a loop in the unlinked inode list, apparently caused by memory corruption on an iSCSI target. I looked into tracking if we already saw a given unlinked inode, but given that we keep walking even for inodes where we can't find an allocation btree record that seems infeasible. On the other hand these inodes had their final unlink and thus were dead even before the system went down. There really is no point in adding them to the uncertain list and looking for references to them later. So the simplest fix seems to be to simply remove the unlinked inode list walk and just clear it - when we rebuild the inode allocation btrees these will simply be marked free. Makes sense to me. Reviewed-by: Mark Tinguely <tinguely@xxxxxxx> |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | XFS status update for December 2011, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 1/4] fs: Improve filesystem freezing handling, Andreas Dilger |
| Previous by Thread: | XFS status update for December 2011, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 02/12] repair: allocate and free inode records individually, Mark Tinguely |
| Indexes: | [Date] [Thread] [Top] [All Lists] |