On Thu, Nov 10, 2016 at 8:46 PM, Manikandan Selvaganesh < manikandancs...@gmail.com> wrote:
> Enabling/disabling quota or removing limits are the ways in which > quota.conf is regenerated to the later version. It works properly. And as > Pranith said, both enabling/disabling takes a lot of time to crawl(though > now much faster with enhanced quota enable/disable process) which we cannot > suggest the users with a lot of quota configuration. Resetting the limit > using limit-usage does not work properly. I have tested the same. The > workaround is based on the user setup here. I mean the steps he exactly > used in order matters here. The workaround is not so generic. > Thanks Manikandan for the reply :). I've not tested this, but went through the code. If I am not wrong, function glusterd_store_quota_config would write a quota.conf which is compatible for versions >= 3.7. This function is invoked by glusterd_quota_limit_usage unconditionally in success path. What am I missing here? @Pranith, Since Manikandan says his tests didn't succeed always, probably we should do any of the following 1. hold back the release till we successfully test limit-usage to rewrite quota.conf (I can do this tomorrow) 2. get the patch in question for 3.9 3. If 1 is failing, debug why 1 is not working and fix that. regards, Raghavendra > However, quota enable/disable would regenerate the file on any case. > > IMO, this bug is critical. I am not sure though how often users would hit > this - Updating from 3.6 to latest versions. From 3.7 to latest, its fine, > this has nothing to do with this patch. > > On Nov 10, 2016 8:03 PM, "Pranith Kumar Karampuri" <pkara...@redhat.com> > wrote: > >> >> >> On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G <raghaven...@gluster.com> >> wrote: >> >>> >>> >>> On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri < >>> pkara...@redhat.com> wrote: >>> >>>> >>>> >>>> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee <amukh...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri < >>>>> pkara...@redhat.com> wrote: >>>>> >>>>>> I am trying to understand the criticality of these patches. >>>>>> Raghavendra's patch is crucial because gfapi workloads(for samba and >>>>>> qemu) >>>>>> are affected severely. I waited for Krutika's patch because VM usecase >>>>>> can >>>>>> lead to disk corruption on replace-brick. If you could let us know the >>>>>> criticality and we are in agreement that they are this severe, we can >>>>>> definitely take them in. Otherwise next release is better IMO. Thoughts? >>>>>> >>>>> >>>>> If you are asking about how critical they are, then the first two are >>>>> definitely not but third one is actually a critical one as if user >>>>> upgrades >>>>> from 3.6 to latest with quota enable, further peer probes get rejected and >>>>> the only work around is to disable quota and re-enable it back. >>>>> >>>> >>>> Let me take Raghavendra G's input also here. >>>> >>>> Raghavendra, what do you think we should do? Merge it or live with it >>>> till 3.9.1? >>>> >>> >>> The commit says quota.conf is rewritten to compatible version during >>> three operations: >>> 1. enable/disable quota >>> >> >> This will involve crawling the whole FS doesn't it? >> >> 2. limit usage >>> >> >> This is a good way IMO. Could Sanoj/you confirm that this works once by >> testing it. >> >> >>> 3. remove quota limit >>> >> >> I guess you added this for completeness. We can't really suggest this to >> users as a work around. >> >> >>> >>> I checked the code and it works as stated in commit msg. Probably we can >>> list the above three operations as work around and take this patch in for >>> 3.9.1 >>> >> >>> >>>> >>>>> >>>>> On a different note, 3.9 head is not static and moving forward. So if >>>>> you are really looking at only critical patches need to go in, that's not >>>>> happening, just a word of caution! >>>>> >>>>> >>>>>> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee <amukh...@redhat.com >>>>>> > wrote: >>>>>> >>>>>>> Pranith, >>>>>>> >>>>>>> I'd like to see following patches getting in: >>>>>>> >>>>>>> http://review.gluster.org/#/c/15722/ >>>>>>> http://review.gluster.org/#/c/15714/ >>>>>>> http://review.gluster.org/#/c/15792/ >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri < >>>>>>> pkara...@redhat.com> wrote: >>>>>>> >>>>>>>> hi, >>>>>>>> The only problem left was EC taking more time. This should >>>>>>>> affect small files a lot more. Best way to solve it is using >>>>>>>> compound-fops. >>>>>>>> So for now I think going ahead with the release is best. >>>>>>>> >>>>>>>> We are waiting for Raghavendra Talur's >>>>>>>> http://review.gluster.org/#/c/15778 before going ahead with the >>>>>>>> release. If we missed any other crucial patch please let us know. >>>>>>>> >>>>>>>> Will make the release as soon as this patch is merged. >>>>>>>> >>>>>>>> -- >>>>>>>> Pranith & Aravinda >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> maintainers mailing list >>>>>>>> maintain...@gluster.org >>>>>>>> http://www.gluster.org/mailman/listinfo/maintainers >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ~ Atin (atinm) >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pranith >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ~ Atin (atinm) >>>>> >>>> >>>> >>>> >>>> -- >>>> Pranith >>>> >>>> _______________________________________________ >>>> Gluster-devel mailing list >>>> Gluster-devel@gluster.org >>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>> >>> >>> >>> >>> -- >>> Raghavendra G >>> >> >> >> >> -- >> Pranith >> >> _______________________________________________ >> maintainers mailing list >> maintain...@gluster.org >> http://www.gluster.org/mailman/listinfo/maintainers >> >> > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > -- Raghavendra G
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel