<div dir="ltr">I took the 512 byte blocksize directly from the recommended latency test in the DRBD manual.<div><br></div><div><a href="http://www.drbd.org/users-guide/s-measure-latency.html">http://www.drbd.org/users-guide/s-measure-latency.html</a><br>
</div><div><br></div><div>"<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px">This test writes 1,000 512-byte chunks of data to your DRBD device, and then to its backing device for comparison. 512 bytes is the smallest block size a Linux system (on all architectures except s390) is expected to handle."</span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px"><br></span></div><div><font color="#000000" face="sans-serif">I'm also performing the same test on a non-DRBD device which performs perfectly fine. So why would I want to tune my tests to yield better results when I have a comparison that is already pointing out a problem in latency?</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 11:10 AM, Arnold Krille <span dir="ltr"><<a href="mailto:arnold@arnoldarts.de" target="_blank">arnold@arnoldarts.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 5 Jun 2014 09:30:37 -0700 Bret Mette<br>
<<a href="mailto:bret.mette@dbihosting.com">bret.mette@dbihosting.com</a>> wrote:<br>
> dd if=/dev/zero of=./testbin bs=512 count=1000 oflag=direct<br>
> 12000 bytes (512 kB) copied, 0.153541 s, 3.3 MB/s<br>
><br>
> This was run against /root/testbin which is /dev/md1 with no LVM or<br>
> DRBD<br>
><br>
><br>
><br>
> dd if=/dev/zero of=./testbin bs=512 count=1000 oflag=direct<br>
> 512000 bytes (512 kB) copied, 32.3254 s, 15.8 kB/s<br>
><br>
> This was run against /mnt/tmp which is DRBD /dev/drbd2 backed by an<br>
> LVM logical volume, with the logical volume backed by /dev/md127 while<br>
> /dev/drbd2 was in the connected state<br>
<br>
</div>Change your dd-parameters for meaningful results!<br>
<br>
Disks are read and written in 4k junks. Writing 512 bytes means<br>
actually reading 4k, replacing the 512 bytes to write, write 4k. Slow<br>
by default!<br>
<br>
Use at least 4k junk size for dd. And use a higher count, 4k * 1000 is<br>
roughly 4M. Most disks today have a cache bigger then that.<br>
<br>
And when you only run your test for 0.15 seconds, you don't even out<br>
background-stuff from the os.<br>
<br>
Using dd for performance tests should result in files of several<br>
gigabytes size.<br>
<br>
The next question is whether you really want to optimize for linear<br>
access which dd kind of measures. Better use a tool like dbench to test<br>
random-access which is a 99.99999% (*) more common usage pattern. Apart<br>
from copying big disk-images or video files, every other use case (even<br>
using disk-images for virtual machines or editing audio-/video-files)<br>
is random access. That means seeking on the harddisk.<br>
<br>
Have fun,<br>
<br>
Arnold<br>
<br>
(*) Could be my estimation is a few 9s short...<br>
<br>_______________________________________________<br>
drbd-user mailing list<br>
<a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br>
<a href="http://lists.linbit.com/mailman/listinfo/drbd-user" target="_blank">http://lists.linbit.com/mailman/listinfo/drbd-user</a><br>
<br></blockquote></div><br></div>