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" <[email protected]>
> To: "James" <[email protected]>
> Cc: "gluster-users" <[email protected]>
> 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 < [email protected] > 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
>
> > [email protected]
>
> > http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
> _______________________________________________
> Gluster-users mailing list
> [email protected]
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
