xfs
[Top] [All Lists]

Re: rsync and corrupt inodes (was xfs_dump problem)

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: rsync and corrupt inodes (was xfs_dump problem)
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 5 Jul 2010 08:53:41 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <201007020821.51753@xxxxxx>
References: <4C26A51F.8020909@xxxxxxxxx> <201007011025.04391@xxxxxx> <20100702024235.GX24712@dastard> <201007020821.51753@xxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Jul 02, 2010 at 08:21:51AM +0200, Michael Monnerie wrote:
> On Freitag, 2. Juli 2010 Dave Chinner wrote:
> > So it's the rsync daemon on saturn that is doing all the IO?
> 
> Yes.
>  
> > > I rsynced today 3 times, twice with the openSUSE kernel and once
> > > with 2.6.34, no problem. Sorry (or maybe "lucky me"?).
> > >
> > > > > 852c268f-cf1a-11de-b09b-806e6f6e6963.vhd* ??????????? ? ?    ?
> > > > >       ?            ? 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd
> > > >
> > > > On the source machine, can you get a list of the xattrs on the
> > > > inode?
> > >
> > > How would I do that? "getfattr" on that file gives no return, does
> > > that mean it doesn't have anything to say? I never do that things,
> > > so there shouldn't be any attributes set.
> > 
> > "getfattr -d"
> 
> Sorry, doesn't work:
> 
> # getfattr -d 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd
> getfattr: 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd: Structure needs 
> cleaning

I meant run it on an uncorrupted version of the file, but I don't
think that information is needed now...

> > The first character of the name is bad, everything after that -
> > including the attribute value - is identical to that on other
> > inodes.  What this implies is that we've overwritten the start of
> > the attribute fork with something, and that looks exactly like the
> > swap extents problems that we've fixed recently....
> > >
> > > Yes, xfs_fsdr was running. Disabled it now, and compiled and
> > > changed to kernel 2.6.34 now. Hope that's OK ;-)
> > 
> > Ok, so we have identified a potential cause. Either disabling fsr or
> > upgrading to 2.6.34 should be sufficient to avoid the problem. If no
> > problem show up now you are on 2.6.34, then I'd switch fsr back on
> > and see if they show up again...
> 
> So far, so good. I'm on 2.6.34 now. Is there any chance for a fixed 
> version of xfs_repair, so that I can either get rid of the 4 broken 
> files (i.e. delete them), or repair the filesystem? ATM, xfs_repair 
> asserts on this filesystem.

What version of xfs_repair? v3.1.2 does not assert fail here on the
metadump image you posted, but it does take 3 runs to fix up all the
problems with the busted inodes....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>