[lkml]   [2006]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: FAQ updated (was Re: XFS breakage...)
    On Thursday 20 July 2006 16:13, Kevin Radloff wrote:
    > On 7/20/06, Nathan Scott <> 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 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:
    > >
    > >
    > > Hope this helps.
    > I actually tried the xfs_db method to fix my / filesystem (as you had
    > outlined in
    >, 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


    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-07-20 19:21    [W:0.023 / U:4.116 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site