Hmm. Maybe there is an issue with 64-bit vs 32-bit use of the same HAMMER filesystem. That hasn't been tested well at all, though theoretically it should work just fine. I think what I need is a full 'hammer -f <device> show' dump of the filesystem. It will be large, but it should be able to bzip2 reasonably well. If you can upload that to leaf I can take a look at it. I also need a list of (a few of the) broken filenames that I can track down, ...

There are many such lines. I have copied the first few ones: BM NODE 800000268ea27000 cnt=33 p=800000268ea12000 type=L depth=4 mirror 000000013a77e4d0 fill=z8:19741=60% { BM NODE 800000268ea31000 cnt=33 p=800000268ea12000 type=L depth=4 mirror 0000000139b6e140 fill=z8:19741=60% { BM NODE 800000268eb0e000 cnt=32 p=800000268eb02000 type=L depth=4 mirror 0000000148774380 fill=z8:19741=60% { BM NODE 800000268eb19000 cnt=32 p=800000268eb02000 type=L depth=4 mirror 0000000139b6e840 ...

If the only flag after B is 'M' then it is ok, it's the mirror-tid bug which was fixed in 2.6 but only effects incremental mirroring. This is self-correcting so it isn't a concern. If other flags are present then we have a real problem. If the broken inodes are localized it could be stuff left dangling from a crash recovery. That's my hope. Did you have any crashes while work was occuring on any of the related directories? If this is the case it should be ...