On Thu, May 30, 2019 at 9:03 AM Ashish Pandey <[email protected]> wrote:
> > > I am only concerned about in-service upgrade. > If a feature/option is not present in V1, then I would prefer not to > enable it by default on V2. > The problem is that without enabling it, (other-)eager-lock will cause performance issues in some cases. It doesn't seem good to keep an option disabled if enabling it solves these problems. > We have seen some problem in other-eager-lock when we changed it to enable > by default. > Which problems ? I think the only issue with other-eager-lock has been precisely that locks-notify-contention was disabled and a bug that needed to be solved anyway. The difference will be that upgraded bricks will start sending upcall notifications. If clients are too old, these will simply be ignored. So I don't see any problem right now. Am I missing something ? > --- > Ashish > > ------------------------------ > *From: *"Amar Tumballi Suryanarayan" <[email protected]> > *To: *"Xavi Hernandez" <[email protected]> > *Cc: *"gluster-devel" <[email protected]> > *Sent: *Thursday, May 30, 2019 12:04:43 PM > *Subject: *Re: [Gluster-devel] Should we enable > features.locks-notify.contention by default ? > > > > On Thu, May 30, 2019 at 11:34 AM Xavi Hernandez <[email protected]> > wrote: > >> Hi all, >> >> a patch [1] was added some time ago to send upcall notifications from the >> locks xlator to the current owner of a granted lock when another client >> tries to acquire the same lock (inodelk or entrylk). This makes it possible >> to use eager-locking on the client side, which improves performance >> significantly, while also keeping good performance when multiple clients >> are accessing the same files (the current owner of the lock receives the >> notification and releases it as soon as possible, allowing the other client >> to acquire it and proceed very soon). >> >> Currently both AFR and EC are ready to handle these contention >> notifications and both use eager-locking. However the upcall contention >> notification is disabled by default. >> >> I think we should enabled it by default. Does anyone see any possible >> issue if we do that ? >> >> > If it helps performance, we should ideally do it. > > But, considering we are days away from glusterfs-7.0 branching, should we > do it now, or wait for branch out, and make it default for next version? > (so that it gets time for testing). Considering it is about consistency I > would like to hear everyone's opinion here. > > Regards, > Amar > > > > >> >> Regards, >> >> Xavi >> >> [1] https://review.gluster.org/c/glusterfs/+/14736 >> _______________________________________________ >> >> > -- > Amar Tumballi (amarts) > > _______________________________________________ > > Community Meeting Calendar: > > APAC Schedule - > Every 2nd and 4th Tuesday at 11:30 AM IST > Bridge: https://bluejeans.com/836554017 > > NA/EMEA Schedule - > Every 1st and 3rd Tuesday at 01:00 PM EDT > Bridge: https://bluejeans.com/486278655 > > Gluster-devel mailing list > [email protected] > https://lists.gluster.org/mailman/listinfo/gluster-devel > > >
_______________________________________________ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-devel
