[Gluster-users] metadata for stat : Should it be identical?

[Brad Childs]

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: [Gluster-users] 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>