Gluster users - Nov 2018 - On making ctime generator enabled by default in stack

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).
* atime consistency. ctime generator offers atime consistency equivalent to
noatime mounts. But, with my limited experience I've not seen too many
usecases that require atime consistency. If you've a usecase please point
it out and we'll think how we can meet that requirement.

[1] https://review.gluster.org/#/c/glusterfs/+/21060/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1600923
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1617972
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1393743

regards,
Raghavendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20181106/dd1619b9/attachment.html>

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?

Thanks,
Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20181105/215d3d86/attachment.html>