<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 6:40 PM Shyam Ranganathan &lt;<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/27/2018 09:08 AM, Shyam Ranganathan wrote:<br>
&gt; Writing this to solicit opinions on merging this [1] change that<br>
&gt; introduces an option late in the release cycle.<br>
&gt; <br>
&gt; I went through the code, and most changes are standard option handling<br>
&gt; and basic xlator scaffolding, other than the change in posix xlator code<br>
&gt; that handles the flag to not set atime and the code in utime xlator that<br>
&gt; conditionally sets the flag. (of which IMO the latter is more important<br>
&gt; than the former, as posix is just acting on the flag).<br>
&gt; <br>
&gt; The option if enabled would hence not update atime for the following<br>
&gt; FOPs, opendir, open, read, and would continue updating atime on the<br>
&gt; following FOPs fallocate and zerofill (which also update mtime, so the<br>
&gt; AFR self heal on time change would kick in anyways).<br>
&gt; <br>
&gt; As the option suggests, with it enables atime is almost meaningless and<br>
&gt; hence it almost does not matter where we update it and where not. Just<br>
&gt; considering the problem where atime changes cause AFR to trigger a heal,<br>
&gt; and the FOPs above that strictly only change atime handled with this<br>
&gt; option, I am looking at this as functionally workable.<br>
&gt; <br></blockquote><div><br></div><div>Thanks for all these details, Shyam! Helps many to understand what the feature is.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; So IMO we can accept this even though it is late, but would like to hear<br>
&gt; from others if this needs to be deferred till release-6.<br>
&gt; <br></blockquote><div><br></div><div>I am all for accepting this for glusterfs-5.0! Two reasons, in one of the quick setup we tried, it helped to get elastic search run smoothly on glusterfs mounts. 2nd, we did hear from Anuradha/Ram in another email thread (Cloudsync with AFR) that it helped them in solving the issue.</div><div><br></div><div>This particular patch makes the overhead of ctime feature much much lesser!</div><div><br></div><div>-Amar</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; Shyam<br>
<br>
[1] Patch under review: <a href="https://review.gluster.org/c/glusterfs/+/21281" rel="noreferrer" target="_blank">https://review.gluster.org/c/glusterfs/+/21281</a><br>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_8444017719621067593gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div>