Re: Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner <david@fromorbit.com>]

On Mon, Jan 13, 2014 at 03:07:30PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 13, 2014, at 11:27 AM, Dave Chinner <david@fromorbit.com> wrote:
> 
> > So, you need to find the inode number of a directory with a corrupt
> > entry, and dump the inode and any data fork blocks that it belongs
> > to with xfs_db similar to what you have just done. 
> 
> 
> Got one. bu[9] is the file that doesn’t work:
.....
> bu[9].inumber = 68719478814
> bu[9].namelen = 26
> bu[9].name = "07 - Se\303\261or Macho Solo.m4v"
> bu[9].tag = 0x130

That looks completely valid. It's a utf-8 encoded directory entry.
It doesn't look like there's any corruption on disk here.

The ls -l output full of ???? usually means the stat of the inode
the dirent pointed to, so that implies that the stat has failed.
So, what does and strace of the 'ls -l' of that directory tell you
about the directory entry that is returned to userspace?

> bleaf[5].hashval = 0x16d07074
> bleaf[5].address = 0x26

That's the hash entry in the directory for the name. That may be
wrong, I guess. can you create another file with the same name
in a different directory so we can check that the hash is correct?

> u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,509696,79700,0]
> 
> I’m not sure if this the right way to get the related first data block. If I did it wrong let me know:
> 
> xfs_db> daddr 509696

fsb 509696, not daddr.

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

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