[Gluster-users] glusterfs performance issues

[Jeff Darcy]

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.  Quorum enforcement doesn't
entirely avoid this, because of the window between failure occurrence and
detection.  To make the solution truly airtight either the clocks need to be
vectors to detect such conditions, or they need to be augmented with flags to
show incomplete operations.  Once such flags exist, the versions themselves add
no value except as an optimistic-concurrency alternative to locking.  Since we
do both locking and dirty flags (which we call the change log) already,
versions would add nothing at all.  We already know from the change log whether
the version we're looking at is potentially out of date.

[1] https://github.com/jdarcy/glusterfs/tree/hsrepl