If the replica took n+1 day to complete, then returning the highest value would show that the file was modified a full day after the user considered it modified. Shouldn't it be the lesser value (if both replicas are consistant)? I n support of James statement f rom a user perspective, I may want to know the last time I wrote some data to a file-- timestamp is metadata for the user. Showing the date gluster completed replicating the file to another node is confusing. -bc ----- Original Message ----- > From: "Anand Avati" <avati at gluster.org> > To: "James" <purpleidea at gmail.com> > Cc: "gluster-users" <gluster-users at gluster.org> > Sent: Thursday, October 24, 2013 7:12:56 PM > Subject: Re: metadata for stat : Should it be identical? > Gluster does have logic to always show mtime which is the highest in value. > It is probably a bug if you are witnessing different mtimes at different > times when no writes have happened in between. > Avati > On Thu, Oct 24, 2013 at 4:31 PM, James < purpleidea at gmail.com > wrote: > > On Thu, 2013-10-24 at 13:00 -0700, Robert Hajime Lanning wrote: > > > > > > > > Design philosophy... > > > > > > > > There is no metadata server. When you look at timestamps in stat, > > > > you > > > > are seeing the real stat of the file. > > > So this raises an interesting point... > > > > > > > > If you have "replica 2" then you have two files. The stat can come > > > > from > > > > either one. Mtime will be the modification time of the file > > > If the replica N files all have slightly different mtimes (it seems they > > > usually will because they weren't written at exactly the same time), > > > then isn't this a point of inconsistency for a script running on a fuse > > > mount which expects the same mtime on a file? > > > Shouldn't gluster somehow coordinate to set all the files mtimes to be > > > consistent to say the last mtime in the replica set? > > > > referenced > > > > by the time on the server (not the client.) > > > > > > > > One of the strengths of GlusterFS is that it does not have the > > > > bottleneck/single point of failure of a single metadata server. > > > _______________________________________________ > > > Gluster-users mailing list > > > Gluster-users at gluster.org > > > http://supercolony.gluster.org/mailman/listinfo/gluster-users > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131025/887b8c7b/attachment.html>
