Fwd: [Gluster-devel] proposals to afr

[Alexey Filin]

yes, but we can't discuss replicas consistency after afr crash if we skip
points which make reasoning wrong. Crash can occur in glfs context only or
as a result of powercut, in bouth cases glfs is to restore replicas
consistency right.

Propose to close the thread, as Krishna said about glfs repairing. The
solution with your flag is the best as difference in size and mtime is not
exhaustive info about unfinished replica updating in some cases after afr
crash. To clean up after powercuts isn't his responsibility but it's a pity
he doesn't believe your solution to be better (probably there are more
important things).

Regards, Alexey.

On 10/25/07, Kevan Benson <kbenson at a-1networks.com> wrote:
>
>
> As I said, I was referring to atomic in the context of GlusterFS.  Using
> locks (thread locks in his case), they can easily prevent any other
> GlusterFS threads from performing an operation on the file).  In that
> respect, it's atomic for that file with respect to GlusterFS.  Other
> processes on the server could of course perform operations at this time,
> which makes the operation not TRULY atomic, just atomic for glusterfs on
> that file, on that system. Perhaps "atomic" was a bad choice of a word
> to convey this.
>
>