public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* 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 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

* 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

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