On 03/28/2013 02:49 PM, Anand Avati wrote:
> Yes, it should, based on the theory of how ext4 was generating the
> 63bits. But Jeff's test finds that the experiment is not matching the
> theory.
FWIW, I was able to re-run my test in between stuff related to That
Other Problem. What seems to be happening is that we read correctly
until just after d_off 0x4000000000000000, then we suddenly wrap around
- not to the very first d_off we saw, but to a pretty early one (e.g.
0x0041b6340689a32e). This is all on a single brick, BTW, so it's pretty
easy to line up the back-end and front-end d_off values which match
perfectly up to this point.
I haven't had a chance to ponder what this all means and debug it
further. Hopefully I'll be able to do so soon, but I figured I'd
mention it in case something about those numbers rang a bell.
Of course, the unit tests (with artificial offsets) were done with brick count >= 2. You have tested with DHT subvol count=1, which was not tested, and sure enough, the code isn't handling it well. Just verified with the unit tests that brick count = 1 condition fails to return the same d_off.
Posting a fixed version. Thanks for the catch!