[Please CC me, I'm not subscribed to the XFS list]
After having upgraded to 2.6.25-rc2 (more precisely
9a4c8546f3e7c893888bccc2b3416d6214f2664a plus wireless-testing) I wanted
to recompile the kernel and ran into weird issues like getting gcc
output to stdout instead of a ccache cache file.
My kernel tree was located on an XFS filesystem and the ccache cache dir
was on another XFS filesystem, both of which were corrupted afterwards,
the kernel tree had some temporary files (.*.d) that were listed in
readdir() but didn't otherwise exist (you could create a file with the
same name but not unlink or even stat the first one).
Also, the ccache cache dir filesystem was corrupted in a way that first
lead to a kernel hang during journal replay, and xfs_repair also hangs
when checking the filesystem even after clearing the journal. I've
uploaded a meta dump of that filesystem to
First I suspected memory corruption or similar issues but after copying
all (relevant) data (reading the ccache cache dir would hang/oops the
kernel) I can now do the same workload on the same kernel with two ext3
filesystems which leads me to believe that XFS caused the corruption in
Unfortunately, because the filesystem with the kernel tree on it was so
large, I don't have a copy of that filesystem, nor have I remembered to
make a copy of either filesystem before zeroing the journal.
Description: This is a digitally signed message part