<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<div align="justify">Hi,<br>
We have exactly the same problem with large files copy.<br>
We're running on Debian 64 bit, with kernel 3.0.3, drbd 8.3.11 and
ocfs2 filesystem. We dedicated 2 10G ports to drbd.<br>
Are you still encountering the same problem? Did you get some
solutions from drbd team? Did you find some tricks on your own?<br>
<br>
Thanks in advance,<br>
<br>
</div>
<br>
Le 16/08/2011 01:24, Dennis Su a écrit :
<blockquote
cite="mid:F1A4661E613ADB448219C0BCBCFF7786031B318C@exc.hemlock.local"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML 8.00.6001.19120">
<div><span class="087551922-15082011"><font face="Arial" size="2">Hi,</font></span></div>
<div><span class="087551922-15082011"></span> </div>
<div><span class="087551922-15082011"><font face="Arial" size="2">We
have two servers built, different hardware and capacity, on
64 bit centos 5.6 with drbd 8.3.8, the backing devices are
gfs2 devices layer on top of LVM, because different capacity
on both nodes and that limits our ability to play with the
barriers effectively. The server has two Gb ports, one
connect to the network and the other connected with a
crossover cable for dedicated drbd sync. We are running a
number of tests to see how well they perform before putting
into production. During the weeks long testing, one thing
doesn't seem right and we've tried to play with the config
to tweak it, but not gaining anything, so we go back to
default for most settings as shown in the drbd show below. </font></span></div>
<div><span class="087551922-15082011"><font face="Arial" size="2">It
is a duo primary setup on a 10TB device. The sync/resync
operations between nodes, without other activities on the
drbd devices, is 63MB (sustained) on both way. However,
adding the write to either node during the sync can cause
the both write and sync speed to drop to 2KB. The situation
can happen on any new write operation as well, initially
the writing, first 10 seconds, are at the expected speed,
then drbd sync kicks in, can see it from the /proc/drbd, it
slows to almost stall, once the sync stopped, observed from
from both ifstat and /proc/drbd, the writing to the node
resume to expected speed, but once the sync start again the
writing slows down. The pattern repeats until the entire
write operation is complete. We have tested with small size
files, the effect is minimum so no problems in there, but we
intent to use these serves to store large files, which can
be few GByte each. Initially, we though that high IO might
be the culprit, then we took drbd out of the picture and
just runs simultaneous read and write tests and they were
fine with large and small files. Now we think that drbd
might need to locked the file to perform the sync, during
locked time the continues write stream on the file is not
permitted, then once the sync is done drbd releases it for
writing again. Then we tried tweaking the buffer and bio, no
help. Of course, this just a guess, but if it is true, is
that any ways to tweak drbd to perform better with big
files.</font></span></div>
<div><span class="087551922-15082011"><font face="Arial" size="2">We
also tried swapping a cross over with a straight cable no
improvements, </font></span></div>
<div><span class="087551922-15082011"></span> </div>
<div><span class="087551922-15082011"><font face="Arial" size="2">Thanks
in advance,</font></span></div>
<div><span class="087551922-15082011"><font face="Arial" size="2">Dennis</font></span></div>
<div><span class="087551922-15082011"><font face="Arial" size="2">###################drbdsetup
/dev/drbd0 show ##############</font></span></div>
<div><span class="087551922-15082011"><font face="Arial" size="2">disk
{<br>
size 0s _is_default; # bytes<br>
on-io-error detach;<br>
fencing dont-care _is_default;<br>
max-bio-bvecs 0 _is_default;<br>
}<br>
net {<br>
timeout 60 _is_default; # 1/10
seconds<br>
max-epoch-size 2048 _is_default;<br>
max-buffers 2048 _is_default;<br>
unplug-watermark 256;<br>
connect-int 10 _is_default; # seconds<br>
ping-int 10 _is_default; # seconds<br>
sndbuf-size 0 _is_default; # bytes<br>
rcvbuf-size 0 _is_default; # bytes<br>
ko-count 0 _is_default;<br>
allow-two-primaries;<br>
cram-hmac-alg "sha1";<br>
shared-secret "<a moz-do-not-send="true"
href="mailto:U$eP@sswd">U$eP@sswd</a>";<br>
after-sb-0pri discard-zero-changes;<br>
after-sb-1pri discard-secondary;<br>
after-sb-2pri disconnect _is_default;<br>
rr-conflict disconnect _is_default;<br>
ping-timeout 5 _is_default; # 1/10
seconds<br>
}<br>
syncer {<br>
rate 112640k; # bytes/second<br>
after -1 _is_default;<br>
al-extents 257;<br>
delay-probe-volume 16384k _is_default; # bytes<br>
delay-probe-interval 5 _is_default; # 1/10
seconds<br>
throttle-threshold 20 _is_default; # 1/10
seconds<br>
hold-off-threshold 100 _is_default; # 1/10
seconds<br>
}<br>
protocol C;<br>
_this_host {<br>
device minor 0;<br>
disk "/dev/mapper/vg0-r0";<br>
meta-disk internal;<br>
address ipv4 10.1.1.35:7788;<br>
}<br>
_remote_host {<br>
address ipv4 10.1.1.29:7788;<br>
}<br>
##############################</font></span></div>
<p><font face="Tahoma" color="#0000ff" size="2">Hemlock Printers,
Ltd.<br>
(604) 439-5075</font></p>
<a moz-do-not-send="true"
title="gfidisc.c8ee20078354b54fb5fd4f35cb32bcdd" href="#"> </a>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
drbd-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a>
<a class="moz-txt-link-freetext" href="http://lists.linbit.com/mailman/listinfo/drbd-user">http://lists.linbit.com/mailman/listinfo/drbd-user</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Christophe Bouder,
</pre>
</body>
</html>