xfs
[Top] [All Lists]

Re: Files with non-ASCII names inaccessible after xfs_repair

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair
From: Zachary Kotlarek <zach@xxxxxxxxxxxx>
Date: Mon, 13 Jan 2014 19:12:07 -0800
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=kotlarek.com; s=default; t=1389669132; bh=oCTfKIyDvUmoUsxyqWVW3/njpLMcLp4hp9bfOxw4pj0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=aW86EfbSvhjMWHjKxu2FmeLcgra6rYJpMNpAw+Mm7eTVFj+TBEVBayJIfC9wZWZgg yjAQ3CdAOitgZrOkNmskU7kgiyHM9EhNQcF+oaQbjMWCjGNWNU6M6A1583mrdj5AOa Kklz5gLu93vsgqjfsAkseSj8Aa8Qg2/J5YO879YE=
In-reply-to: <20140114022414.GM3469@dastard>
References: <A40DF90D-5F6B-4595-AA30-B91D8F7972D0@xxxxxxxxxxxx> <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>
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)


>> 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:

bleaf[0].hashval = 0x2e
bleaf[0].address = 0x2
bleaf[1].hashval = 0x172e
bleaf[1].address = 0x4
bleaf[2].hashval = 0x1052379a
bleaf[2].address = 0x22
bleaf[3].hashval = 0x16d0707c
bleaf[3].address = 0x3b
bleaf[4].hashval = 0x3d1c0738
bleaf[4].address = 0x1b
bleaf[5].hashval = 0x3d1c0739
bleaf[5].address = 0x18
bleaf[6].hashval = 0x3d1c073a
bleaf[6].address = 0x15
bleaf[7].hashval = 0x3d1c073b
bleaf[7].address = 0x12
bleaf[8].hashval = 0x3d1c073c
bleaf[8].address = 0xf
bleaf[9].hashval = 0x3d1c073d
bleaf[9].address = 0xc
bleaf[10].hashval = 0x3d1c073e
bleaf[10].address = 0x9
bleaf[11].hashval = 0x3d1c073f
bleaf[11].address = 0x6
bleaf[12].hashval = 0x7f92e42b
bleaf[12].address = 0x2b
bleaf[13].hashval = 0x9f92e6c0
bleaf[13].address = 0x36


>> 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.


xfs_db> fsb 509696 
xfs_db> p
000: 0000001c 66747970 6d703432 00000000 6d703432 69736f6d 61766331 00000084

And that looks like the MP4 magic number across the first 3 segments, which is 
what I’m expecting.

        Zach

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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