<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018 at 8:25 PM Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com">rgowdapp@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018 at 11:41 PM Vijay Bellur <<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 8:31 PM Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 9:58 AM Vijay Bellur <<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018 at 7:56 PM Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">All,<br><br>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. <br><br></div><div>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).<br><br></div><div>As to the existing known issues/limitations with ctime generator, my conversations with Kotresh, revealed following:<br></div><div>* 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).<br></div></div></div></div></div></blockquote><div><br></div><div>Do we have this data captured somewhere? If not, would it be possible to share that data here?</div></div></div></blockquote><div><br></div><div>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.<br> </div></div></div></blockquote><div><br></div><div>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?</div></div></div></div></blockquote><div><br></div><div>No. Perf benchmarking is a task pending on me.<br></div></div></div></blockquote><div><br></div><div>When can we expect this task to be complete?</div><div><br></div><div>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? </div><div><br></div><div>We could:</div><div><br></div><div>1. Revert the patch now</div><div>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.</div><div>3. Think of some other option?</div><div><br></div><div>Thanks,<br></div><div>Vijay</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>
</blockquote></div></div>