Hello again everyone, I was able to perform the steps I proposed last week: On Mon, Jul 25, 2011 at 11:28:51AM -0700, Keith Keller wrote: > --take another backup > --umount all XFS filesystems (the OS filesystems are ext3) > --remove the kmod-xfs CentOS package > --update to the latest CentOS kernel and reboot, making sure > the target XFS fs does not have a mount attempted > --run xfs_repair from xfsprogs-3.1.5 > --cross fingers :) > --mount and check what's in lost+found For posterity sake, I thought I should post my results. Everything went very smoothly, actually--even though the repair of the metadump I took reported errors, when I worked with the actual filesystem, it fixed superblock 0 but otherwise found no errors. The xfs_repair took about 42 minutes, compared to about 35-40 minutes to operate (on similar but different hardware) on the metadump. That's really nice performance--I had to e2fsck a ~5TB filesystem the other day, and it took about 5 hours total. > --if all seems well, attempt another xfs_growfs using xfsprogs-3.1.5 I haven't yet attempted this final step. I am going to wait till I return from another vacation to do so. :) But I am hopeful that with the latest kernel available from the CentOS repos that I should be fine. Is there a way to directly query the running module for version information, so that I can try to verify that I have a version that will work? Here's my uname, if it's helpful: Linux xxxxxxxxxx 2.6.18-238.19.1.el5 #1 SMP Fri Jul 15 07:31:24 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux --keith -- kkeller@xxxxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
