Some questions on HAMMER internals

[Vasily Postnicov]

Hello.

I have read that data corresponding to any file in HAMMER fs is stored in
8-megabyte blocks (I believe, they are called big-blocks). Also, all
inodes, directory entries, etc. are indexed in a global per-FS B+tree. If
one, for example, changes a file, a new element in the tree is created,
starting with new "create transaction id" and an old element's delete
transaction id is updated, so, in this way, the history is maintained.

Suppose then, that I read from a file with path /hammer_mountpoint/a or
from older version of the same file /hammer_mountpoint/@@0x<tid>/a. So how
corresponding data in big blocks can be found? If a search in the B-tree is
performed, then what key is used?

Also, each element in the tree has a 4-byte "localization" field. The first
two bytes is a PFS id. What are the last two? What are "rt", "ot", "key"
and "dataof" fields shown by "hammer show" command? Is that correct, that
PFSes have their own obj and inode space, so if I mirror one PFS to
another, B-tree will have elements with the same obj fields, but with
different localization?

Can anybody again explain what "fake transaction id" means? I read man 1
undo, but still cannot get it.

And the last question (it's the reason why I try to understand HAMMER a bit
more): I cannot access a file in a snapshot generated by "hammer snapq"
command. "undo -ai" shows many fake transaction ids and kernel prints a
message:

HAMMER: WARNING: Missing inode for dirent "midori"
        obj_id = 0000000272ed2679, asof =0000000280c49ec0, lo=00030000

It can happen for an arbitrary tid, but how can it be for a snapshot tid
(in my case, 0x0000000280c49ec0)? Current versions of all files seems to be
OK. Should I send a bug report?

      With regards, Vasily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/hammer/attachments/20150315/1ea83330/attachment.htm>