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> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
