<div dir="ltr">On Fri, Oct 25, 2013 at 12:51 PM, James <span dir="ltr"><<a href="mailto:purpleidea@gmail.com" target="_blank">purpleidea@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Oct 25, 2013 at 3:18 PM, Anand Avati <<a href="mailto:avati@gluster.org">avati@gluster.org</a>> wrote:<br>
> In normal operations they will differ as much as the time drift between the<br>
> servers + lag in delivery/issue of write() calls on the servers. This delta<br>
> is "fixed up" by consistently returning the highest of the two mtimes<br>
> whenever queried.<br>
<br>
<br>
</div>But lets says we have replica == 2.<br>
On server A this mtime is 4:45<br>
On server B this mtime is 4:46<br>
So fuse queries the times, and it returns the max, which is 4:46.<br>
All is good.<br>
Suppose now that server B is down, and the query is run again.<br>
It should now return 4:45, although this means that file has changed mtime.<br>
This could break client operations, which may care about a change in mtime.<br>
<br>
Note that I don't expect differences of 1 minute, but I just chose<br>
arbitrary values to make understanding the example easier.<br>
<br>
So isn't this a bug?<br></blockquote><div><br></div><div>This is a known behavior - when a server goes down, files can witness a changed mtime (but I don't think that is what the original post was about). We could provide a new feature/enhancement to keep mtimes in sync with explicit utimes() call per-write() - but that might be too expensive for most users.</div>
<div><br></div><div>Avati</div></div></div></div>