[Gluster-users] On making ctime generator enabled by default in stack

[Vijay Bellur]

On Sun, Nov 11, 2018 at 8:25 PM Raghavendra Gowdappa <rgowdapp at redhat.com>
wrote:

>
>
> On Sun, Nov 11, 2018 at 11:41 PM Vijay Bellur <vbellur at redhat.com> wrote:
>
>>
>>
>> On Mon, Nov 5, 2018 at 8:31 PM Raghavendra Gowdappa <rgowdapp at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Nov 6, 2018 at 9:58 AM Vijay Bellur <vbellur at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Nov 5, 2018 at 7:56 PM Raghavendra Gowdappa <
>>>> rgowdapp at redhat.com> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> There is a patch [1] from Kotresh, which makes ctime generator as
>>>>> default in stack. Currently ctime generator is being recommended only for
>>>>> usecases where ctime is important (like for Elasticsearch). However, a
>>>>> reliable (c)(m)time can fix many consistency issues within glusterfs stack
>>>>> too. These are issues with caching layers having stale (meta)data
>>>>> [2][3][4]. Basically just like applications, components within glusterfs
>>>>> stack too need a time to find out which among racing ops (like write, stat,
>>>>> etc) has latest (meta)data.
>>>>>
>>>>> Also note that a consistent (c)(m)time is not an optional feature, but
>>>>> instead forms the core of the infrastructure. So, I am proposing to merge
>>>>> this patch. If you've any objections, please voice out before Nov 13, 2018
>>>>> (a week from today).
>>>>>
>>>>> As to the existing known issues/limitations with ctime generator, my
>>>>> conversations with Kotresh, revealed following:
>>>>> * Potential performance degradation (we don't yet have data to
>>>>> conclusively prove it, preliminary basic tests from Kotresh didn't indicate
>>>>> a significant perf drop).
>>>>>
>>>>
>>>> Do we have this data captured somewhere? If not, would it be possible
>>>> to share that data here?
>>>>
>>>
>>> I misquoted Kotresh. He had measured impact of gfid2path and said both
>>> features might've similar impact as major perf cost is related to storing
>>> xattrs on backend fs. I am in the process of getting a fresh set of
>>> numbers. Will post those numbers when available.
>>>
>>>
>>
>> I observe that the patch under discussion has been merged now [1]. A
>> quick search did not yield me any performance data. Do we have the
>> performance numbers posted somewhere?
>>
>
> No. Perf benchmarking is a task pending on me.
>

When can we expect this task to be complete?

In any case, I don't think it is ideal for us to merge a patch without
completing our due diligence on it. How do we want to handle this scenario
since the patch is already merged?

We could:

1. Revert the patch now
2. Review the performance data and revert the patch if performance
characterization indicates a significant dip. It would be preferable to
complete this activity before we branch off for the next release.
3. Think of some other option?

Thanks,
Vijay


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20181111/8fdee77d/attachment.html>