On Thu, Mar 28, 2013 at 3:14 PM, Anand Avati <anand.avati@xxxxxxxxx> wrote:
On Thu, Mar 28, 2013 at 12:43 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:On 03/28/2013 02:49 PM, Anand Avati wrote:FWIW, I was able to re-run my test in between stuff related to That
> 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.
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!
Posted an updated version http://review.gluster.org/4711. This passes unit tests for all brick counts (>= 1). Can you confirm if the "loop"ing is now gone in your test env?
Thanks,
Avati
