Messages in this thread | | | From | Alistair John Strachan <> | Subject | Re: FAQ updated (was Re: XFS breakage...) | Date | Thu, 20 Jul 2006 17:51:40 +0100 |
| |
On Thursday 20 July 2006 16:13, Kevin Radloff wrote: > On 7/20/06, Nathan Scott <nathans@sgi.com> wrote: > > On Wed, Jul 19, 2006 at 12:21:08PM +0200, Kasper Sandberg wrote: > > > On Wed, 2006-07-19 at 08:57 +1000, Nathan Scott wrote: > > > > On Wed, Jul 19, 2006 at 12:29:41AM +0200, Torsten Landschoff wrote: > > > > > Jul 17 07:33:53 pulsar kernel: xfs_da_do_buf: bno 16777216 > > > > > Jul 17 07:33:53 pulsar kernel: dir: inode 54526538 > > > > > > > > I suspect you had some residual directory corruption from using the > > > > 2.6.17 XFS (which is known to have a lurking dir2 corruption issue, > > > > fixed in the latest -stable point release). > > > > Correction there - no -stable exists with this yet, I guess that'll > > be 2.6.17.7 once its out though. > > > > > what action do you suggest i do now? > > > > I've captured the state of this issue here, with options and ways > > to correct the problem: > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > > > > Hope this helps. > > I actually tried the xfs_db method to fix my / filesystem (as you had > outlined in > http://marc.theaimsgroup.com/?l=linux-kernel&m=115070320401919&w=2), and > while it's quite possible that I screwed it up, after a subsequent > xfs_repair run (which completed successfully and moved lots of stuff to > /lost+found, as I would expect), the XFS code had serious problems with > various parts of my filesystem (like "ls /lost+found", which > would cause lots of errors to be logged, although not a complete fs > shutdown). After another run through xfs_repair resulted in a > filesystem that would no longer even successfully boot. > > Unfortunately it was a mostly-full 74GB big-/ partition on my primary > machine (a laptop), so I don't have a dump of it for you and my report > is probably pretty useless. :( But on the bright side, virtually all > of the filesystem was otherwise intact and I was able to get all my > data off before rebuilding my system.
I've been hit by this on my root filesystem today, and when I followed the instructions, I was able to retrieve my data. It turned out that the only corrupted inode was /, which unfortunately meant I had to repair the filesystem with a boot-cd. However, it was obvious which inodes corresponded to which directories, and I was able to repair it.
I'm not sure this advice is sound, but it seems to me that if you're running an affected 2.6.17 kernel (or ever have) on an XFS volume, it's not worth risking destruction if you haven't had any oopses. The filesystem will get worse, but hopefully in a non-fatal way, and the XFS guys will hopefully have an xfs_repair up that works, soon.
Right now I'd highly recommend copying as much as possible from the corrupted filesystem )after following the instructions) to a new filesystem (with an unaffected kernel, of course) and destroying the old one. I still have inconsistencies on the filesystem I "repaired", and it was a fairly painful process.
-- Cheers, Alistair.
Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |