On Tue, 10 Feb 2009 15:56:21 +0530, Anand Avati
wrote:
>> One other thing occurs to me - in cases where multicast isn't directly
>> available, an externel helper/replicator would be equally useful for
>> emulating a similar thing.
>>
>> For example, if I have 4 systems on 2Mb pipes (e.g. DSL) and
> One other thing occurs to me - in cases where multicast isn't directly
> available, an externel helper/replicator would be equally useful for
> emulating a similar thing.
>
> For example, if I have 4 systems on 2Mb pipes (e.g. DSL) and have a system
> at a colo on a cheal all-I-can-eat 10Mb pipe,
On Fri, 6 Feb 2009 15:57:57 +0530, Vikas Gorur wrote:
> Gordon,
>
> (Replying to both your mails)
>
> Implementing multicast would be difficult since multicasting only
> works for UDP, and GlusterFS relies on a TCP connection. Moving GlusterFS
> to use UDP would require extensive changes and wou
Gordon,
(Replying to both your mails)
Implementing multicast would be difficult since multicasting only
works for UDP, and GlusterFS relies on a TCP connection. Moving GlusterFS
to use UDP would require extensive changes and would bring many new problems
of its own.
Regarding the configuration y
One other thing occurs to me - in cases where multicast isn't directly
available, an externel helper/replicator would be equally useful for
emulating a similar thing.
For example, if I have 4 systems on 2Mb pipes (e.g. DSL) and have a system
at a colo on a cheal all-I-can-eat 10Mb pipe, it would m
I'm working on putting a WAN AFR setup at the moment, and it occurs to me
that the point-to-point nature of client-to-multiple-servers replication is
extremely inefficient. For example, if I have 4 nodes, that means that
every write has to be done 3 times over the WAN to 3 different remote
servers.
