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

[Kaushal M]

Posted changes for review,
https://review.gluster.org/10425
https://review.gluster.org/10426

~kaushal

On Tue, Apr 28, 2015 at 6:34 PM, Kaushal M <kshlmster at gmail.com> wrote:
> 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