[Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Kaushal M]

After a long discussion (not really), we've concluded that a 64-bit
uint is really overkill for how we are using the generation number,
and I'll change it to a 32-bit uint. I'll send a change to do this
right away.

The generation number we use is not permanent, it is valid only within
a GlusterD processe's lifetime. It starts fresh on every GlusterD
start. We don't save it or restore it. The generation number is bumped
for each peerinfo object allocated. Considering this, even if were to
do peer probes every second it'd be ages before we overflow with a
32-bit generation number. If someone is somehow able to bombard us
with 4 billion requests, I expect GlusterD to bork before the
generation number ever reaches the overflow point.

~kaushal

On Tue, Apr 28, 2015 at 6:13 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:
> On Tue, Apr 28, 2015 at 06:08:45PM +0530, Vijay Bellur wrote:
>> Let us retain support for 32-bit platforms. Though as developers we do not
>> run many tests on non 64-bit platforms, it would be not be good to break
>> compatibility for 32-bit platforms as we have many community users running
>> this
>
> That is a point in favor of not migrating NetBSD slave VM running
> regression to 64 bit systems. Keeping them as is will catch any
> 32 bit regressuin.
>
> --
> Emmanuel Dreyfus
> manu at netbsd.org