Re: Files with non-ASCII names inaccessible after xfs_repair

Zachary Kotlarek
2014-01-14T03:12:18Z

[-- Attachment #1.1: Type: text/plain, Size: 2717 bytes --]

On Jan 13, 2014, at 6:24 PM, Dave Chinner <david@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)

>> 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 #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]