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@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
