Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Mon, Jan 13, 2014 at 07:12:07PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 13, 2014, at 6:24 PM, Dave Chinner <david at fromorbit.com> wrote:
> 
> >> 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?
> 
> It just returns ENOENT:
> stat("/mnt/media/TV/30 Rock/Season 3/07 - Señor Macho Solo.m4v", 0x15990f0) = -1 ENOENT (No such file or directory)
> lstat("/mnt/media/TV/30 Rock/Season 3/07 - Señor Macho Solo.m4v", 0x15990f0) = -1 ENOENT (No such file or directory)

Ok, so it's a lookup failure.

> >> 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?
> 
> bu[16].inumber = 9255716888
> bu[16].namelen = 26
> bu[16].name = "07 - Se\303\261or Macho Solo.m4v"
> bu[16].tag = 0x1d8
> 
> I don’t understand how to find the right bleaf, but 0x16d07074 doesn’t appear in any of the hashvals for that directory:

Pretty simple - the leaf[].address is simply a compressed offset
into the leaf. all dirents are 8 byte aligned, and the tag is the
byte offset into the leaf dirent space. Hence:

	leaf[].address = bu[16].tag >> 3
			= 0x1d8 >> 3
			= 0x3b
			= bleaf[3].address

> bleaf[3].hashval = 0x16d0707c
> bleaf[3].address = 0x3b

And there were are - there's a single bit discrepancy in the lower
byte of the hash. That tends to imply we have a bug in xfs_repair.

What version of xfs_repair did you use? (xfs_repair -V)

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com