[Gluster-users] glusterfs performance issues

[Rob Gil]

Cassandra does this interestingly enough and is more baked than the suggestions posed thus far. As it is an eventual consistency database it needs to pull the freshest ID of a record, similar to a file. That ID is based on a timestamp and a server hash (potentially more things). It might be worth looking in to if this is not fully baked. I have not seen the issues Stephen has been mentioning though. I've been running in production on 3.3 without incident. 

On Jan 8, 2013, at 8:07 AM, Stephan von Krawczynski <skraw at ithnet.com> wrote:

> 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
> 
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users