[DragonFlyBSD - Bug #3378] (New) hammer2(8) recover: bad InodeHash2 hash calculation

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #3378 has been reported by tkusumi.

----------------------------------------
Bug #3378: hammer2(8) recover: bad InodeHash2 hash calculation
http://bugs.dragonflybsd.org/issues/3378

* Author: tkusumi
* Status: New
* Priority: Normal
* Target version: 6.6
* Start date: 2025-01-19
----------------------------------------
InodeHash2 in hammer2(8) recover directive is expected to have a shorter linked list for a given InodeHash2[hv2] than InodeHash[hv]. But InodeHash2 often has much longer linked lists with limited number of buckets being used.

The problem is that xor'd (bref->data_off >> 10) often clears the inode number bits, and as a result many inode blockrefs have the same hv2. (bref->data_off >> 10) part is supposed to be spreading hash values, but actually doing the opposite.

e.g. Below is an example of (bref->key ^ (bref->key >> 16)) and (bref->data_off >> 10) for inode blockrefs in a non-corrupt HAMMER2 volume with relatively small number of inodes. In this volume, all non-root inodes had 0x32400 for hv2. This is an extreme case, but InodeHash2 always have much longer average lists with way fewer buckets being used.

<pre>
0x400 0x32000
0x401 0x32001
0x402 0x32002
0x403 0x32003
...
0x500 0x32100
0x501 0x32101
0x502 0x32102
0x503 0x32103
...
0x600 0x32200
0x601 0x32201
0x602 0x32202
0x603 0x32203
...
0x700 0x32300
0x701 0x32301
0x702 0x32302
0x703 0x32303
...
</pre>



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account