Re: Files with non-ASCII names inaccessible after xfs_repair

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs

[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux