[Gluster-devel] Wrong assumptions about disperse
srangana at redhat.com
Fri Jun 17 13:59:05 UTC 2016
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
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
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?
More information about the Gluster-devel