Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, 5 Jun 2014 09:30:37 -0700 Bret Mette <bret.mette at dbihosting.com> wrote: > dd if=/dev/zero of=./testbin bs=512 count=1000 oflag=direct > 12000 bytes (512 kB) copied, 0.153541 s, 3.3 MB/s > > This was run against /root/testbin which is /dev/md1 with no LVM or > DRBD > > > > dd if=/dev/zero of=./testbin bs=512 count=1000 oflag=direct > 512000 bytes (512 kB) copied, 32.3254 s, 15.8 kB/s > > This was run against /mnt/tmp which is DRBD /dev/drbd2 backed by an > LVM logical volume, with the logical volume backed by /dev/md127 while > /dev/drbd2 was in the connected state Change your dd-parameters for meaningful results! Disks are read and written in 4k junks. Writing 512 bytes means actually reading 4k, replacing the 512 bytes to write, write 4k. Slow by default! Use at least 4k junk size for dd. And use a higher count, 4k * 1000 is roughly 4M. Most disks today have a cache bigger then that. And when you only run your test for 0.15 seconds, you don't even out background-stuff from the os. Using dd for performance tests should result in files of several gigabytes size. The next question is whether you really want to optimize for linear access which dd kind of measures. Better use a tool like dbench to test random-access which is a 99.99999% (*) more common usage pattern. Apart from copying big disk-images or video files, every other use case (even using disk-images for virtual machines or editing audio-/video-files) is random access. That means seeking on the harddisk. Have fun, Arnold (*) Could be my estimation is a few 9s short... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20140605/7659cb12/attachment.pgp>