On Sun, Nov 11, 2018 at 8:25 PM Raghavendra Gowdappa <[email protected]> wrote:
> > > On Sun, Nov 11, 2018 at 11:41 PM Vijay Bellur <[email protected]> wrote: > >> >> >> On Mon, Nov 5, 2018 at 8:31 PM Raghavendra Gowdappa <[email protected]> >> wrote: >> >>> >>> >>> On Tue, Nov 6, 2018 at 9:58 AM Vijay Bellur <[email protected]> wrote: >>> >>>> >>>> >>>> On Mon, Nov 5, 2018 at 7:56 PM Raghavendra Gowdappa < >>>> [email protected]> 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 >
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-devel
