On 10/25/13 13:33, Anand Avati wrote: > On Fri, Oct 25, 2013 at 12:51 PM, James <purpleidea at gmail.com > <mailto:purpleidea at gmail.com>> wrote: > > On Fri, Oct 25, 2013 at 3:18 PM, Anand Avati <avati at gluster.org > <mailto:avati at gluster.org>> wrote: > > In normal operations they will differ as much as the time drift > between the > > servers + lag in delivery/issue of write() calls on the servers. > This delta > > is "fixed up" by consistently returning the highest of the two mtimes > > whenever queried. > > > But lets says we have replica == 2. > On server A this mtime is 4:45 > On server B this mtime is 4:46 > So fuse queries the times, and it returns the max, which is 4:46. > All is good. > Suppose now that server B is down, and the query is run again. > It should now return 4:45, although this means that file has changed > mtime. > This could break client operations, which may care about a change in > mtime. > > Note that I don't expect differences of 1 minute, but I just chose > arbitrary values to make understanding the example easier. > > So isn't this a bug? > > > 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. Also, the time used would have to be sent from the client (using the client's time.) Otherwise, every query will cause a time negotiation between all servers to figure out the "proper" time. Then it will be on the users to keep all clients sync'd, or you will have competing time updates. -- Mr. Flibble King of the Potato People
