<div>Digimer,</div><div><br></div><div><br></div><div>Thanks for your answer. DRBD Proxy could be a solution, but it is not possible for today. </div><div><br></div><div>I am thinking of trying DRBD with protocol A, but currently I am not able to test on my environment as it is in production. I will have maintenance window on the weekend. Do you think it can help? If yes, may you suggest values for tcp send buffer?</div>
<div><br></div><div>Thanks in advance.</div><div><br></div><div>Best regards</div><div>Piotr Kandziora</div><div><br></div><br><br><div class="gmail_quote">On Thu, Feb 16, 2012 at 4:43 PM, Digimer <span dir="ltr"><<a href="mailto:linux@alteeve.com">linux@alteeve.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7k">Hi Piotr,<br>
<br>
Samba (and similar protocols) are generally pretty forgiving of<br>
network issues, so it's not a surprise that they work where DRBD does<br>
not. DRBD is designed for high speed/low latency environments, and has a<br>
fair bit of attention paid to fault detection and recovery. If it sees a<br>
network fault, even a short one, it has to assume the link has failed<br>
and recovery is needed. This does not lend itself well to use on<br>
slow/error prone networks.<br>
<br>
Is it possible to use a wired connection for the DRBD replication? If<br>
not, I would suggest looking at DRBD Proxy instead, as it is designed to<br>
run over slow/unstable links, but it is asynchronous, so be advised that<br>
consistency is not always guaranteed.</div></blockquote></div><br>