[Gluster-devel] Wrong assumptions about disperse

[Shyam]

On 06/17/2016 04:59 AM, Xavier Hernandez wrote:

Firstly, thanks for the overall post, was informative and helps clarify 
some aspects of EC.

> AFAIK the real problem of EC is the communications
> layer. It adds a lot of latency and having to communicate simultaneously
> and coordinate 6 or more bricks has a big impact.

Can you elaborate this more? Is this coordination cost lesser if EC is 
coordinated from the server side graphs? (like leader/follower models in 
JBR)? I have heard some remarks about a transaction manager in Gluster, 
that you proposed, how does that help/fit in to resolve this issue?

I am curious here w.r.t DHT2, where we are breaking this down into DHT2 
client and server pieces, and on the MDC (metadata cluster), the leader 
brick of DHT2 subvolume is responsible for some actions, like in-memory 
inode locking (say), which would otherwise be a cross subvolume lock 
(costlier).

We also need transactions when we are going to update 2 different 
objects with contents (simplest example is creating the inode for the 
file and linking its name into the parent directory), IOW when we have a 
composite operation.

The above xaction needs recording, which is a lesser evil when dealing 
with a local brick, but will suffer performance penalties when dealing 
with replication or EC. I am looking at ways where this xaction 
recording can be compounded with the first real operation that needs to 
be performed on the subvolume, but that may not always work.

So what are your thoughts in regard to improving the client side 
coordination problem that you are facing?

Thanks,
Shyam