On Mon, Jan 13, 2014 at 03:07:30PM -0800, Zachary Kotlarek wrote: > > On Jan 13, 2014, at 11:27 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > So, you need to find the inode number of a directory with a corrupt > > entry, and dump the inode and any data fork blocks that it belongs > > to with xfs_db similar to what you have just done. > > > 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? > 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? > 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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
