RUMI Szabolcs wrote:
> Well, what could be the reason? I mean, there was no hardware failure,
> no crash, no reboot, no errors in the disk's SMART error log, no nothing.
> What I did was that I've extracted and deleted the rather huge OpenOffice
> source tree several times (sometimes with overwriting) and finally it
> ended up with these undeletable files and xfs errors. Is it considered
> normal for xfs to get messed up like that under such load?
No, not normal.
It found the text "0xAAAA0000,6,0x" on disk in an area where it expected
to find valid filesystem metadata.
Corruption could come from anywhere - an xfs bug, some other bug, bad
memory, bad cables, neon death rays from space, writing directly to the
disk, who knows. Awfully hard to track down a one-off occurrence like
this, I'm afraid.
> The xfs_repair output and xfs_info output is included below:
> # xfs_repair -v /dev/sda10
> Phase 6 - check inode connectivity...
> - resetting contents of realtime bitmap and summary inodes
> - traversing filesystem ...
> - agno = 0
> - agno = 1
> - agno = 2
> - agno = 3
> - agno = 4
> - agno = 5
> - agno = 6
> - agno = 7
> leaf block 8388608 for directory inode 4051737 bad header
> rebuilding directory inode 4051737
> leaf block 8388608 for directory inode 4053318 bad header
> rebuilding directory inode 4053318
above is the problem, properly found & repaired.