xfs
[Top] [All Lists]

Re: Files with non-ASCII names inaccessible after xfs_repair

To: Zachary Kotlarek <zach@xxxxxxxxxxxx>
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 15 Jan 2014 12:53:50 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <BE0C947E-37DE-4CA1-B120-59B95E1E8EB8@xxxxxxxxxxxx>
References: <52D2E358.6070106@xxxxxxxxxxxxxxxxx> <CF41F386-E86A-4745-B28D-0DAA8D3CA1DD@xxxxxxxxxxxx> <20140113015007.GC3469@dastard> <EDB09149-717F-4089-9C21-1D342CF77A7D@xxxxxxxxxxxx> <20140113031947.GG3469@dastard> <E2EE0AEA-ED22-4D3B-8550-88F2ED1F8314@xxxxxxxxxxxx> <20140113192732.GI3469@dastard> <0E45339E-04C4-4775-B6B0-FC55245B0AED@xxxxxxxxxxxx> <20140114022414.GM3469@dastard> <BE0C947E-37DE-4CA1-B120-59B95E1E8EB8@xxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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[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@xxxxxxxxxxxxx

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