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@xxxxxxxxxx> 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@xxxxxxxxxx _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
