XFS internal error after upgrading kernel to 2.6.17.13
 

Hi!

After upgrading the kernel to version 2.6.17.13 included in XFS I got some XFS internal error. HD activity doesn't appear compromised, though, but... I don't feel comfortable with them and couldn't discover, yet, to what these errors are due. My root partition is an xfs partition on /dev/hda3 (it's an ATA drive). I didn't modify the script that load modules (rc.modules-2.6.17.13) because they always worked perfectly in my compaq nc6000. The error which pops up is:

Filesystem "hda3": XFS internal error xfs_da_do_buf(2) at line 2212 of file fs/xfs/xfs_da_btree.c. Caller 0xe0ac57d9

I can reproduce the error in bash simply writing xfs and pressing TAB!

Anyone saw this error and know the reason which produced it?

I read that some bug in older 2.6.17 kernel existed (still exists?) which caused a corruption of an xfs filesystem. BTW, the strange thing is that as soon as I upgraded the kernel, error messages begin to appear! smart says the disk shows no problem.

I would like to run xfs_repair but I can't mount this disk on another machine. Furthermore, I tried remounting / read only (with mount -r -o remount /) but xfs_repair still reports the fs as mounted and writable. I temporarily linked mtab to /proc/mounts but this did not resolve xfs_repair issue...

I start cursing the day I chose xfs... :scratch:

Neither modifying mtab and then remount / read only has succeeded in getting xfs_repair recognize the filesystem as read only... I've got a big headache...

The number of answers indicated that this problem, fortunately, isn't common. BTW, I post the solution in case someone needs it. As said, there was a kernel bug in the 2.6.17 series (up to 2.6.17.7 included) which *might* cause a corruption in xfs filesystem.

xfsprogs didn't work with a mounted and readonly filesystem (my root fs was xfs and could not unmount it nor boot with another os) reporting that the filesystem was still writable. SGI support suggested me to upgrade to xfsprogs 2.8.11-1 and lately we discovered that xfs_resize wouldn't work unless I soft linked /dev/root to the real device. Indeed, my /proc/mounts (in the system I boot with an initrd to load xfs kernel module) is similar to:
rootfs / rootfs rw 0 0
/dev/root / xfs rw 0 0

Linking /dev/root to the real device solved the problem and xfs_repair could do its work.

Bye,
Enrico.