xfs
[Top] [All Lists]

Re: xfs_repair 3.2.0 cannot (?) fix fs

To: Arkadiusz MiÅkiewicz <arekm@xxxxxxxx>
Subject: Re: xfs_repair 3.2.0 cannot (?) fix fs
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 30 Jun 2014 13:44:15 +1000
Cc: Alex Elder <elder@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140630031810.GC4453@dastard>
References: <201406290001.38493.arekm@xxxxxxxx> <201406282352.56431.arekm@xxxxxxxx> <201406280141.54350.arekm@xxxxxxxx> <20140630031810.GC4453@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jun 30, 2014 at 01:18:10PM +1000, Dave Chinner wrote:
> On Sat, Jun 28, 2014 at 01:41:54AM +0200, Arkadiusz MiÅkiewicz wrote:
> > 4) 
> > Phase 7 - verify and correct link counts...
> > Invalid inode number 0xfeffffffffffffff
> > xfs_dir_ino_validate: XFS_ERROR_REPORT
> > Metadata corruption detected at block 0x11fbb698/0x1000
> > libxfs_writebufr: write verifer failed on bno 0x11fbb698/0x1000
> > Invalid inode number 0xfeffffffffffffff
> > xfs_dir_ino_validate: XFS_ERROR_REPORT
> > Metadata corruption detected at block 0x11fbb698/0x1000
> > libxfs_writebufr: write verifer failed on bno 0x11fbb698/0x1000
> > done
> 
> Not sure what that is yet, but it looks like writing a directory
> block found entries with invalid inode numbers in it. i.e. it's
> telling me that there's something not been fixed up.
> 
> I'm actually seeing this in phase4:
> 
>         - agno = 148
> Invalid inode number 0xfeffffffffffffff
> xfs_dir_ino_validate: XFS_ERROR_REPORT
> Metadata corruption detected at block 0x11fbb698/0x1000
> libxfs_writebufr: write verifer failed on bno 0x11fbb698/0x1000

OK:

repair/dir2.c:#define   BADFSINO ((xfs_ino_t)0xfeffffffffffffffULL)

And:

                /*
                 * Now we can mark entries with BADFSINO's bad.
                 */
                if (!no_modify && ent_ino == BADFSINO) {
                        dep->name[0] = '/';
                        *dirty = 1;
                        junkit = 0;
                }

So these errors:

> entry at block 22 offset 560 in directory inode 419558142 has illegal name 
> "/_198.jpg": clearing entry

Appear to be a result of repair failing at some point before phase
6 which cleans up bad inodes and entries in the directory structure.

> So regardless of whether metadump handles them or is not going to
> change the fact that filenames with "/" them are broken....
> 
> But the real question here is how did you get "/" characters in
> filenames? 

Yup, there are several places where repair overwrites the dirent name
with a leading "/" to indicate a junked entry, and this is supposed
to be detected and handled in phase 6.  Seems like the directory is
not being rebuilt in phase 6?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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