Re: xfs_repair 3.2.0 cannot (?) fix fs

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs