On Thu, Mar 28, 2013 at 3:14 PM, Anand Avati <anand.av...@gmail.com> wrote:
> On Thu, Mar 28, 2013 at 12:43 PM, Jeff Darcy <jda...@redhat.com> wrote: > >> 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! > 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
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
