* Reading directory entries from BMAP
@ 2007-10-04 14:27 cyjoyp
2007-10-04 16:52 ` Bhagi rathi
2007-10-04 23:26 ` David Chinner
0 siblings, 2 replies; 4+ messages in thread
From: cyjoyp @ 2007-10-04 14:27 UTC (permalink / raw)
To: xfs
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]]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Reading directory entries from BMAP 2007-10-04 14:27 Reading directory entries from BMAP cyjoyp @ 2007-10-04 16:52 ` Bhagi rathi 2007-10-05 5:16 ` cyjoyp 2007-10-04 23:26 ` David Chinner 1 sibling, 1 reply; 4+ messages in thread From: Bhagi rathi @ 2007-10-04 16:52 UTC (permalink / raw) To: cyjoyp; +Cc: xfs 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. On 10/4/07, cyjoyp <cyjoyp@gmail.com> wrote: > > > 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]] > > > [[HTML alternate version deleted]] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reading directory entries from BMAP 2007-10-04 16:52 ` Bhagi rathi @ 2007-10-05 5:16 ` cyjoyp 0 siblings, 0 replies; 4+ messages in thread From: cyjoyp @ 2007-10-05 5:16 UTC (permalink / raw) To: xfs 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 Bhagi rathi wrote: > >>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. > > On 10/4/07, cyjoyp <cyjoyp@gmail.com> wrote: >> >> >> 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]] >> >> >> > > > [[HTML alternate version deleted]] > > > > -- 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reading directory entries from BMAP 2007-10-04 14:27 Reading directory entries from BMAP cyjoyp 2007-10-04 16:52 ` Bhagi rathi @ 2007-10-04 23:26 ` David Chinner 1 sibling, 0 replies; 4+ messages in thread From: David Chinner @ 2007-10-04 23:26 UTC (permalink / raw) To: cyjoyp; +Cc: xfs On Thu, Oct 04, 2007 at 07:27:19AM -0700, cyjoyp wrote: > > 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; > } 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(). > > 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 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.... > 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.. 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-10-05 5:16 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-10-04 14:27 Reading directory entries from BMAP cyjoyp 2007-10-04 16:52 ` Bhagi rathi 2007-10-05 5:16 ` cyjoyp 2007-10-04 23:26 ` David Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox