[DRBD-user] drbd 0.7 vs 8 latency

X LAci lanlaf at index.hu
Fri Jan 2 11:01:23 CET 2009


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




More information about the drbd-user mailing list