[Gluster-users] glusterfs performance issues

[Stephan von Krawczynski]

On Tue, 08 Jan 2013 07:54:05 -0500
Jeff Darcy <jdarcy at redhat.com> wrote:

> On 1/8/13 7:11 AM, Stephan von Krawczynski wrote:
> > Nobody besides you is talking about timestamps. I would simply choose an
> > increasing stamp, increased by every write-touch of the file.
> > In a trivial comparison this assures you choose the latest copy of the file.
> > There is really no time needed at all, and therefore no time synchronisation
> > issues.
> 
> When you dismiss change logs and then say "latest" without elaboration then
> it's not unreasonable to assume you mean timestamps.  Perhaps you should try to
> write more clearly.
> 
> Versions are certainly an improvement over timestamps, but they're not as
> simple as you say either - and I've actually used versioning in a functional
> replication translator[1] so I'm not just idly speculating about work other
> people might do.  If two replicas are both at (integer) version X but are
> partitioned from one another, then writes to both could result in two copies
> each with version X+1 but with different data.

This can only happen in a broken versioning. Obviously one would take (very
rough explanation) at least a two-shot concept. You increase the version by
one when starting the file modification process and again by one when the
process is completed without error.
You end up knowing that version nr 1,3,5,... are intermediate/incomplete
versions and 2,4,6,... are files with completed operations.
Now you can tell at any time throughout any stat comparison which file is
truely actual and which one is in intermediate state. If you want that you can
even await the completion of an ongoing modification before returning some
result to your requesting app. Yes, this would result in immanent locking.

-- 
Regards,
Stephan