Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Mike, You can read about these options on this page: http://www.drbd.org/users-guide-emb/re-drbdconf.html The safest setting for a non-battery backed up raid is to not use any of these options, because if you use them, and there is a power outage, or your PC crashes, you will lose data, so your data integrity is lowering. But if you have a UPS and a software to shut down your PC when there is a power outage, and your PC does not crash all that often, you may consider it. This only affects latency, small writes suffer with the default settings. On Thu, 2009-01-01 at 18:03 -0800, Mike Sweetser - Adhost wrote: > 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 > > > > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user