Re: On-disk data for XFS_DINNODE_FMT_EXTENTS

[Brian Foster <bfoster@redhat.com>]

On Tue, Nov 03, 2015 at 10:48:53AM +0100, hoper@free.fr wrote:
> Hi,
> 
> I'm trying to understand how xfs is storing informations,
> but I guess that my documentation "XFS Filesystem Structure
> 2nd Edition Revision 2" is quite outdated :(
> 
> I made an XFS filesystem, then made 60 files in /.
> 
> # xfs_db -f /root/small 
> xfs_db> inode 128
> xfs_db> addr
> current
> 	byte offset 32768, length 256
> 	buffer block 64 (fsbno 8), 8 bbs
> 	inode 128, dir inode 128, type inode
> xfs_db> p
> core.magic = 0x494e
> core.mode = 040755
> core.version = 2
> core.format = 2 (extents)
> [...]
> next_unlinked = null
> u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,12,1,0]
> 
> I made a small script in python which retrieve all theases information from disk,
> except the "12" (location of the X2DB block = 12*4096). From the manuel, and my 
> understanding, this information, 12, should be found just next the di_unlinked.
> (page 43 on the manuel). But from an hex editor, from addr 32768, I got this :
> 
> 49 4E 41 ED 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01
> 56 37 5D 71 2D 26 3D 0B 56 37 5D 6C 02 78 F1 EC 56 37 5D 6C 02 78 F1 EC 00 00 00 00 00 00 10 00
> 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00
> FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 01 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00
> 
> First, 49 4E (IN) that's the begining of the inode core (96 bytes). All informations are here,
> and match the output of xfs_db. But after next_unlinked (FF FF FF FF here), and until next IN, 
> I can't find any 12 :( Where is it ?
> 

The extent information is encoded in a format that's not easily
interpreted from a raw hex dump. See xfs_iformat_extents() to start:

                dp = (xfs_bmbt_rec_t *) XFS_DFORK_PTR(dip, whichfork);
                xfs_validate_extents(ifp, nex, XFS_EXTFMT_INODE(ip));
                for (i = 0; i < nex; i++, dp++) { 
                        xfs_bmbt_rec_host_t *ep = xfs_iext_get_ext(ifp, i);
                        ep->l0 = get_unaligned_be64(&dp->l0);
                        ep->l1 = get_unaligned_be64(&dp->l1);
                }

So we start after di_next_unlinked and read in two 64-bit, big endian
fields. That data in your dump above is:

l0: 0x0000000000000000
l1: 0x0000000001800001

Then, these 64-bit fields have a special encoding themselves to map to
actual extent data. From xfs_format.h:

/*
 * Bmap btree record and extent descriptor.
 *  l0:63 is an extent flag (value 1 indicates non-normal).
 *  l0:9-62 are startoff.
 *  l0:0-8 and l1:21-63 are startblock.
 *  l1:0-20 are blockcount.
 */

We see that l0 is completely zeroed, so we can infer that this is a
normal extent and startoff is zero. The block count is l1:0-20, which is
00001b or 1. The start block is (((l0 & 0x1FF) << 43) | (l1 >> 21)),
which is:

	((0x0 & 0x1FF) << 43) | (0x1800001 >> 21)
	 0x0		      |  0xC
		= 0xC == 12

See __xfs_bmbt_get_all() for the code that implements this decoding.

Brian

> Lot's of thanks to anyone that could give me help on this subject.
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

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