<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hello.<br><br></div>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.<br><br></div>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?<br><br></div>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?<br><br></div>Can anybody again explain what "fake transaction id" means? I read man 1 undo, but still cannot get it.<br><br></div>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:<br><br></div>HAMMER: WARNING: Missing inode for dirent "midori"<br></div>        obj_id = 0000000272ed2679, asof =0000000280c49ec0, lo=00030000<br><br></div>It can happen for an<span> arbitrary tid, but how can it be for a snapshot tid (in my case, 0x</span><span>0000000280c49ec0)? Current versions of all files seems to be OK. Should I send a bug report?<br><br></span></div><span>      With regards, Vasily.<br></span></div>