On 02/17/2014 04:42 PM, Gionatan Danti wrote:
On 02/17/2014 11:18 AM, Vijay Bellur wrote:
write-behind can help with write operations but the lookup preceding the
write is sent out to all bricks today and hence that affects overall
performance.
Ok, this is in-line with my tests and the auto-generated configuration
files
Not as of today.
One possibility is to let local clients assume that the remote target is
not reachable and hence all operations happen locally. self-heal-daemon
can perform background syncs when they notice that there is a delta.
Achieving this form of near synchronous replication will involve some
amount of work. If the same file is updated from multiple sites, then
there are chances of running into split-brains and we would need good
conflict resolution mechanisms too.
I thought the same thing, but what scary me is that I expect split-brain
to be quite common, even when using frequent volume heal cycles (eg:
each 15 min). The problem is that users are likely to work with the same
office files. From what I understand, a split-brain scenario led to
unaccessible files until the split-brain condition is solvede (which
implies manual operation at the hard-link level). Is that true?
Yes, split-brains need to be resolved manually. We are exploring the
possibility of evolving policies to resolve certain split-brains
automatically.
-Vijay
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
