[Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Pranith Kumar Karampuri]

On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G <raghavendra at gluster.com>
wrote:

>
>
> On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
> pkarampu at redhat.com> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee <amukherj at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
>>> pkarampu at 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 <amukherj at 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 <
>>>>> pkarampu at 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
>>>>>> maintainers at gluster.org
>>>>>> http://www.gluster.org/mailman/listinfo/maintainers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> ~ Atin (atinm)
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> ~ Atin (atinm)
>>>
>>
>>
>>
>> --
>> Pranith
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Raghavendra G
>



-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20161110/f8ea787c/attachment-0001.html>