xfs_bmbt_rec_64 leading to wrong blocks

[Brian Foster]

On Wed, Aug 06, 2014 at 12:12:12PM +0200, Felipe Monteiro de Carvalho wrote:
> Hello,
> 
> I am writing a software which reads xfs partitions and it is working
> well so far, but, at in a particular folder with 10k files, only 7k
> files appear, the other ones don't.
> 
> I read an inode which has di_core.di_format = XFS_DINODE_FMT_BTREE
> 
> No problem here, the btree is trivial, it has only 1 element inside
> it, which leads to a list of 82 extends.
> 
> Extends 0..52 aprox. are all great, and work fine.
> 
> Extent 53 (and other ones after that) point to very wierd memory areas
> which don't match the pattern that I saw previously =(
> 
> Here is the hex data of the extents, the selected extent in nr 53:
> 
> http://magnifier.sourceforge.net/temp/xfs/extent_with_xfs_bmbt_rec_64.png
> 
> And here is debug information showing which values I extracted from this table:
> 
> i=0 FLocalExtent.StartOff=0 FLocalExtent.StartBlock=66748
> FLocalExtent.BlockCount=1 lStartBlock=65212
> i=1 FLocalExtent.StartOff=1 FLocalExtent.StartBlock=66758
> FLocalExtent.BlockCount=2 lStartBlock=65222
> i=2 FLocalExtent.StartOff=3 FLocalExtent.StartBlock=66772
> FLocalExtent.BlockCount=1 lStartBlock=65236
> ....
> 
> i=51 FLocalExtent.StartOff=77 FLocalExtent.StartBlock=67468
> FLocalExtent.BlockCount=1 lStartBlock=65932
> i=52 FLocalExtent.StartOff=78 FLocalExtent.StartBlock=67479
> FLocalExtent.BlockCount=1 lStartBlock=65943
> i=53 FLocalExtent.StartOff=8388608 FLocalExtent.StartBlock=66749
> FLocalExtent.BlockCount=1 lStartBlock=65213
> i=54 FLocalExtent.StartOff=8388609 FLocalExtent.StartBlock=66783
> FLocalExtent.BlockCount=2 lStartBlock=65247
> ...
> 
> Note how StartOff is suddenly so big! But I manually checked the bits
> comparing to xfs_bmbt_rec_64 and the value written is that one. But
> what sense does it make for StartOff to jump like that?
> 

Assuming 4k blocks, 8388608 is 32G, which is the offset interval used
for some internal sections of directories on XFS. If this is a
directory, it could be a node/leaf or freelist block. Looking at
xfs_da_format.h, it looks like XFS_DIR2_LEAF_OFFSET points to this
offset. This block basically points to a btree of hashed entry names for
lookup. See here for basics:

http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/Directories.html

... and here for a diagram:

http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/Node_Directories.html

> And why are the blocks pointing to a non-XD2D block?
> 
> Here is the block to which one of the valid extents point to:
> 
> http://magnifier.sourceforge.net/temp/xfs/correct_block_xd2d.png
> 
> And here is a block to which one of the extents that I cannot
> interpretate point to:
> 
> http://magnifier.sourceforge.net/temp/xfs/wierd_block_xd2d.png
> and another one:
> http://magnifier.sourceforge.net/temp/xfs/wierd_xfs_dir2_data_entry.png
> 

The 0xFEBE magic seems to confirm the second one as a node block.

Brian

> Any ideas???
> 
> I already worked so much on this, but I cannot figure out =(
> 
> thanks,
> -- 
> Felipe Monteiro de Carvalho
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs