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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Nov 12, 2018 at 10:48 AM Amar Tumballi <atumball@xxxxxxxxxx> wrote:


On Mon, Nov 12, 2018 at 10:39 AM Vijay Bellur <vbellur@xxxxxxxxxx> wrote:


On Sun, Nov 11, 2018 at 8:25 PM Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:


On Sun, Nov 11, 2018 at 11:41 PM Vijay Bellur <vbellur@xxxxxxxxxx> wrote:


On Mon, Nov 5, 2018 at 8:31 PM Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:


On Tue, Nov 6, 2018 at 9:58 AM Vijay Bellur <vbellur@xxxxxxxxxx> wrote:


On Mon, Nov 5, 2018 at 7:56 PM Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> 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.

I am for option 2. Considering the branch out for next release is another 2 months, and no one is expected to use the 'release' off a master branch yet, it makes sense to give that buffer time to get this activity completed.

Its unlikely I'll have time for carrying out perf benchmark. Hence I've posted a revert here: https://review.gluster.org/#/c/glusterfs/+/21975/


Regards,
Amar

3. Think of some other option?

Thanks,
Vijay
 
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users


--
Amar Tumballi (amarts)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux