metadata for stat : Should it be identical?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 25, 2013 at 9:14 AM, Brad Childs <bdc at redhat.com> wrote:

> If the replica took n+1 day to complete,
>

Gluster's replication is synchronous. So writes are done in parallel. If a
server was down and we self-heal it later, we sync both data and mtime.


> 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)?
>
> In support of James statement from 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.
>
>
As I described above, that is not the case. Delayed replication (healing)
happens for both data and mtime.

Avati



>
> -bc
>
>
> ------------------------------
>
> *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/2ee2b240/attachment.html>


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux