Re: Resolving data_offset and data_len

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

Daniel Lorch wrote:
> >     Reading the data via the B-Tree is a bit confusing because data_offset 
> >     in a B-Tree element is *NOT* the base offset for the data block but
> >     instead the ending offset for the data block.  i.e. the offset in
> >     the file for the data is actually (cursor.leaf->data_offset -
> >     cursor.leaf->data_len).
>
> What does cursor.leaf->data_len represent? Is it the data record's
> length in KB? (so it would be either 16K or 64K).

cursor.leaf->base.key is the logical *end* (in bytes) of the extent
cursor.leaf->data_len is the length of the extent in bytes
cursor.leaf->data_offset is the HAMMER internal offset (see below)

> Does (cursor.leaf->data_offset - cursor.leaf->data_len) represents a
> *byte offset* from the beginning of the block device? Or is it a
> relative value to some other value?

It is a HAMMER_ZONE_LARGE_DATA offset.  Disk offsets in HAMMER are all 
64bit, but do not directly refer to byte offsets on the disk.  Instead the 
offsets have multiple layers (or at least one) of indirections.  See 
hammer_disk.h:120 for reference.  Basically the right thing to do is use 
hammer_io_direct_read().

good luck
  simon

--
  <3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /"\
  rock the past  +++  space for low €€€ NOW!1  +++     Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \