Reading directory entries from BMAP

Hi there,
I am a beginner in learning XFS file system.. I have a doubt, dont
know whether is silly..If you could help me with this...Thank you..

An extent is 128 bit in size and uses the following struct,

        typedef struct xfs_bmbt_irec {
                      xfs_fileoff_t              br_startoff;
                      xfs_fsblock_t            br_startblock;
                      xfs_filblks_t              br_blockcount;
                      xfs_exntst_t             br_state;
                     }
     
     I have got in to the BMAP position after traversing the BTREE..
     The BMAP has a leaf and no other siblings..
     I have the extents for directory entries stored in the BMAP..
     This is where is struck badly..
   
    Now I have a 16 byte value from which I can calculate the block count
,AG number ,etc...
             00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02

In this case I lan up some where else instead going to the block of
directory entries..
This br_startoff (logical offset) is causing a difference...I am going
wrong somwhere in this case..

Could you please tell me br_startoff does really mean???

View this message in context: http://www.nabble.com/Reading-directory-entries-from-BMAP-tf4569129.html#a13040897
Sent from the Xfs - General mailing list archive at Nabble.com.


[[HTML alternate version deleted]]

br_startoff is starting offset of a file. The problem you are facing is not clear to me.
XFS uses 16 bytes to represet start offset, length of the extent and then start bloock
offset.

If you are interested with directories of XFS, the blocks that start from 0 offset and with
in the file address space of 32GB is the name space. After name space, you have
lookup space and then free space manager for directories. Typically, reading of
directory entries is reading of the total blocks reported by stat command. A directory
can be in single block format, embedded in the inode itself, etc.

You are talking about bmbt_irec and then going towards directory entries. This was
not clear to me.

-Saradhi.

[[HTML alternate version deleted]]

Thanks for your reply....
I ll make it clear for you....

Manipulating this 16 bytes

00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02

*21 bits out of A0 00 02 would form the block count : 2
*19 bits out of 00 00 A0 would form the absolute block numbe :15h *The remaining bits out 52 (52-19 =33 bits) would form the AG number : 0 *The rest forms the logical offset.

This means that I have to read 2 contiguos blocks from the location
15h*8=168.
I really dont understand how the logial offset works.
More I have the root folder with 1000 empty directoris created in the
root.
So when I go to the position 168,I should be able to see only two
contigous blocks of directory entries,
but I am not getting ..

Instead I get values

sector number: 168

00  80  00  03  00  80  00  02  d2  ff  00  00  01  2e  00 00
b8  16  e9  8d  00  00  06  ed  b8 16 e9  8e  00  00  06 e8
b8  16  e9  8f   00  00  06  e3  be  95 a0 c2  00  00  0e 6b
be  95  a0  c3  00  00  0e  66  be  95 a0 c8  00  00  0e 4d
be  95  a0  c9  00  00  0e  48  be  95 a0 ca  00  00  0e 43

There is no magic number at the start ...

Are you able to understand??

thnks

not

0

reading

View this message in context: http://www.nabble.com/Reading-directory-entries-from-BMAP-tf4569129.html#a13053632
Sent from the Xfs - General mailing list archive at Nabble.com.

That's the unpacked, in-memory format. The on disk format for extents is converted by xfs_bmbt_set_allf/xfs_bmbt_disk_set_allf().

If that is the start of the block, theres a block header first, right? i.e.:

/*
* * Bmap root header, on-disk form only.
* */
typedef struct xfs_bmdr_block {
__be16 bb_level; /* 0 is a leaf */
__be16 bb_numrecs; /* current # of data records */
} xfs_bmdr_block_t;

So the above woul dbe telling me that this is a level zero block (a leaf), with one record. Then there's the first record in packed format....

unpack the extent record first before decoding it. Perhaps you should be using xfs_db to look at your disk structures rather than trying to manually decode it from hex dumps. i.e.:

# xfs_db -r -c "inode 128" -c "p core.size core.nblocks core.format u.bmx"  -c "dblock 0" -c "type dir2" -c p /dev/sdb8
core.size = 4096
core.nblocks = 1
core.format = 2 (extents)
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,132,1,0]
bhdr.magic = 0x58443242
bhdr.bestfree[0].offset = 0x618
bhdr.bestfree[0].length = 0x770
bhdr.bestfree[1].offset = 0x370
bhdr.bestfree[1].length = 0x128
bhdr.bestfree[2].offset = 0x88
bhdr.bestfree[2].length = 0x58
bu[0].inumber = 128
bu[0].namelen = 1
bu[0].name = "."
bu[0].tag = 0x10
bu[1].inumber = 128
bu[1].namelen = 2
bu[1].name = ".."
bu[1].tag = 0x20
bu[2].inumber = 131
bu[2].namelen = 3
bu[2].name = "tmp"
bu[2].tag = 0x30
bu[3].inumber = 132
bu[3].namelen = 11
bu[3].name = "syscalltest"
bu[3].tag = 0x40
......

Note that this will print the entire block, including unused space with it's stale contents.

Cheers,

Dave.

Dave Chinner
Principal Engineer
SGI Australian Software Group