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
