I now did the following: - I put the disks of an affected machine (not the original one in this bug report) into a Debian6 machine which has been running rock-solid with XFS for years - I used a script of my own to generate checksums & file date listing of ALL files (~2.5TB) on the disks using the Debian6. - I then used an USB stick with Ubuntu12.04 to run xfs_repair on the affected XFS. - After repair finished, I again put the disks into the Debian6 machine an generated checksums / filedate listing. - I diff'ed the pre-repair and post-repair checksums and filedates. They are absolutely identical.
Conclusion: The fact that the Debian did not complain about corruption when generating the checksums and that the checksums are not affected by repair maybe shows that there is no actual physical corruption but it was rather a crash bug? I will put the affected machine back into operation with a 3.6 kernel as requested. HOWEVER I should say that it took multiple weeks of operation until the issue first happened, so I don't think that testing this with 3.6 will disprove anything any soon. I think you guys should read the changelogs of the kernels or actually look at the stack trace and see what happened :| -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1049267 Title: XFS corruption on machine which never suffered a hard reset or disk failure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049267/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
