Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Feb 09, 2011 at 12:51:24PM -0600, J. Ryan Earl wrote:
> On Sat, Feb 5, 2011 at 4:45 AM, ionral <daniele.nuzzo at email.it> wrote:
>
> > if I check the status of drbd the following response is:
> >
> > 0: cs: Connected ro: Primary / Primary ds: UpToDate / UpToDate C r ----
> > ns: 640864680 nr: 135234784 dw: 776099464 dr: 1520599328 al: 836478 bm:
> > 2185 lo: 0 pe: 0 ua: 0 ap: 0 ep: 1 wo: b OOS: 0
> >
> > I do not know if it is positive that the method is to write after is
> > Barrier
> > .... reading the manuals of drbd I noticed that in these cases (BBU)
> > performance would be better for a wo:n
> >
> > What do you think?
> >
>
> Modify your drbd.conf to look more like:
>
> disk {
> on-io-error detach;
> # It is good to have backed up write caches
> no-disk-barrier;
> no-disk-flushes;
> no-disk-drain;
Do not use "no-disk-drain", unless you are absolutely sure that nothing
in the IO stack below DRBD could possibly reorder writes.
> no-md-flushes;
> use-bmbv;
With recent DRBD (>= 8.3.8), use-bmbv is a no-op.
With older DRBD, it can cause spurious detaches
on the Secondary, so don't use that either,
unless you absolutely know what you are doing.
> }
>
> This will completely turn off write ordering which. I have measured
> performance gains doing this with backed-up write caches.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed