<br><br><div class="gmail_quote">On Thu, Mar 28, 2013 at 12:43 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 03/28/2013 02:49 PM, Anand Avati wrote:<br>
> Yes, it should, based on the theory of how ext4 was generating the<br>
> 63bits. But Jeff's test finds that the experiment is not matching the<br>
> theory.<br>
<br>
</div>FWIW, I was able to re-run my test in between stuff related to That<br>
Other Problem. What seems to be happening is that we read correctly<br>
until just after d_off 0x4000000000000000, then we suddenly wrap around<br>
- not to the very first d_off we saw, but to a pretty early one (e.g.<br>
0x0041b6340689a32e). This is all on a single brick, BTW, so it's pretty<br>
easy to line up the back-end and front-end d_off values which match<br>
perfectly up to this point.<br>
<br>
I haven't had a chance to ponder what this all means and debug it<br>
further. Hopefully I'll be able to do so soon, but I figured I'd<br>
mention it in case something about those numbers rang a bell.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Posting a fixed version. Thanks for the catch!</div><div><br></div><div>Avati</div><div><br></div></div>