On Tue, 2013-04-16 at 11:44 -0700, Keith Keller wrote: > On 2013-04-16, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > Not recently. What version of xfs_repair are you using? > > Hmm, perhaps this is a difference. I believe (though, again I did very > poor logging, and I apologize) that the initial repair used 3.1.1. The > recent successful repair definitely used 3.1.10. Is it possible 3.1.1 > is old enough that it might not have caught the issues I reported from > the 3.1.10 log? > Yes, we had a system here for which xfs_repair 3.1.6 reported for 30 or so files: data fork in regular inode 3238731555 claims used block 1080914355 correcting nblocks for inode 3238731555, was 304 - counted 0 in phase three, and correcting nblocks for inode 3238731555, was 0 - counted 304 in phase four, so the filesystem ended up back where it started. Version 3.1.8 fixed this, reporting instead e.g.: data fork in regular inode 3238731617 claims used block 1080933203 correcting nextents for inode 3238731617 correcting nblocks for inode 3238731617, was 304 - counted 0 correcting nextents for inode 3238731617, was 1 - counted 0 > -- Roger Willcocks <roger@xxxxxxxxxxxxxxxx> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
