Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On another note, what would probably be the best ones to use on a non-battery backup, SATA RAID setup for DRBD? And will adding these to an existing configuration cause any issues? Mike Sweetser -----Original Message----- From: drbd-user-bounces at lists.linbit.com on behalf of X LAci Sent: Thu 1/1/2009 12:14 PM To: drbd-user at lists.linbit.com Subject: Re: [DRBD-user] drbd 0.7 vs 8 latency Dear all, Happy new year to all who is celebrating. Lars was right. no-disk-barrier; no-disk-flushes; no-md-flushes; All three of these was needed to bring back the io performance to the 0.7 level. I've read in the documentation that these should be used only on BBWC RAID, but I didn't know that a simple SATA disk based system also needs this for higher performance. By default 8.3.0 uses disk-barrier, if one disables this, then it uses flush, if that is disabled also, then comes the drain method. Thanks for the help. Best regards, lanlaf On Wed, 2008-12-31 at 16:18 +0100, Lars Ellenberg wrote: > On Wed, Dec 31, 2008 at 12:52:41PM +0100, X LAci wrote: > > Dear all, > > > > I ran into high latency with drbd 8.3.0, on the same hardware where drbd > > 0.7 was OK. > > > > I have created a test system Yesterday, two Lenovo Thinkcenter PCs, P4 > > 3.0 GHz, Intel Chipset, 1 SATA disk in each PC, Gigabit Ethernet, one > > cable between them. I've installed Debian Etch on each of them, and drbd > > 0.7 that came with Etch. Drbd 8.3.0 was compiled by me. > > > > One goal was to verify that 0.7 -> 8 version upgrade goes without data > > loss. That is succeeded, there was no data loss. > > > > I have tested the performance as described in the performance tuning > > webinar. > > > > Hdparm and dd showed that the disks are capable of reading and writing > > at about 62 MByte/sec. > > > > The disk latency for each node: > > > > dd if=/dev/zero of=/dev/sda3 bs=512 count=1000 oflag=direct > > > > node1: 512000 bytes (512 kB) copied, 0.158945 seconds, 3.2 MB/s > > node2: 512000 bytes (512 kB) copied, 0.158367 seconds, 3.2 MB/s > > > > For initial sync, I put resync rate to 60 MByte/sec so that it finishes > > quickly. The actual resync rate was around 48 MByte/sec. > > > > Throughput was OK with 8.3.0, bs=300M count=1, 60.3 MByte/sec. > > > > Latency with drbd 0.7 was acceptable also: > > > > dd if=/dev/zero of=/dev/drbd0 bs=512 count=1000 oflag=direct > > 512000 bytes (512 kB) copied, 0.308893 seconds, 1.7 MB/s > > > > Latency with drbd 8.3.0 was very bad: > > > > dd if=/dev/zero of=/dev/drbd0 bs=512 count=1000 oflag=direct > > 512000 bytes (512 kB) copied, 8.36032 seconds, 61.2 kB/s > > > > It was not resyncing, there was no other activity on the PCs. > > > > I've also tried with drbd 8.2.6, same results. Also tried with Debian > > Etch 2.6.18 and 2.6.24-etchnhalf kernel, same results. > > > > drbd.conf was basicly default, only put in disk and network parameters, > > resync rate was changed to 20 Mbyte/sec, and al-extents 1201. > > > > What could cause this problem? > > drbd 0.7 has no idea about disk flushes or barriers, > so on volatile caches it may cause data loss on power outage. > > drbd 8 by default cares very much about explicitly flushing > or inserting barriers into the data stream to avoid this problem. > however when running on huge (controller) caches, and if the > implementation of "flush" is indeed a full cache flush, > these frequent flushes can degrade performance considerably. > > they are not even necessary when your cache is batter backed. > > so if you are running on a "safe" device > (either NON-volatile, battery backed, cache; or no cache at all), > consider turning these additional flushes off: > > no-disk-barrier; > no-disk-flushes; > no-md-flushes; > > > _______________________________________________ drbd-user mailing list drbd-user at lists.linbit.com http://lists.linbit.com/mailman/listinfo/drbd-user -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090101/a4856e7a/attachment.htm>