On Mon, Jan 13, 2014 at 07:12:07PM -0800, Zachary Kotlarek wrote:
> On Jan 13, 2014, at 6:24 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> >> Got one. bu is the file that doesnât work:
> > .....
> >> bu.inumber = 68719478814
> >> bu.namelen = 26
> >> bu.name = "07 - Se\303\261or Macho Solo.m4v"
> >> bu.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.hashval = 0x16d07074
> >> bleaf.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.inumber = 9255716888
> bu.namelen = 26
> bu.name = "07 - Se\303\261or Macho Solo.m4v"
> bu.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.tag >> 3
= 0x1d8 >> 3
> bleaf.hashval = 0x16d0707c
> bleaf.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)