[DRBD-user] remote buffer cache

Lars Ellenberg lars.ellenberg at linbit.com
Thu Oct 25 11:24:05 CEST 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Tue, Oct 23, 2012 at 11:03:14AM +0200, Thilo Uttendorfer wrote:
> Hi,
> 
> the man-page of drbd.conf says about protocol B "...completed, if it has 
> reached local disk and remote buffer cache".
> 
> How can I determine the size of the remote buffer cache? Is this cache also 
> limited by the "max-buffers" option?

DRBDs max-buffers settings has something to do with it,
but that does not change between DRBD protocols.

There are pictures somewhere in those "papers" linked from the
documentation page. iirc.

Anyways, I'll try some ascii art:

Protocol C:
===========

  Primary                               Secondary
   incoming
  |         .
 t|         |\     data transfer latency
 i|  local  | `------>>-->>-->>-->>-->>-->>---. <- received the data
 m|  submit |                                 |
 e|         - local completion                | remote IO subsystem latency
  |                                           |
  |                                           |
  |                                          ,- remote completion
  |                 remote write ACK        /
  | COMPLETE <------<<--<<--<<--<<--<<--<<-´
  v

  If some client has seen a sucessful "commit",
  the cluster may even have a simultaneous power outage/crash,
  in which the primary is destroyed, still nothing is lost.

Protocol B:
===========

  Primary                               Secondary
   incoming
  |         .
 t|         |\     data transfer latency
 i|  local  | `------>>-->>-->>-->>-->>-->>---. <- received the data
 m|  submit |                                 |
 e|         - local completion               /| remote IO subsystem latency
  |               remote receive ACK        / |
  | COMPLETE <------<<--<<--<<--<<--<<--<<-´  |
  |                                           - remote completion
  |
  |
  v

  If some client has seen a sucessful "commit",
  the primary node may fail, and nothing is lost,
  as long as the other node stays up and takes over.

Protocol A:
===========

  Primary                               Secondary
   incoming
  |         .
 t|         |\     data transfer latency
 i|  local  | `------>>-->>-->>-->>-->>-->>---. <- received the data
 m|  submit |                                 |
 e| COMPLETE- local completion                | remote IO subsystem latency
  |                                           |
  |                                           |
  |                                           - remote completion
  |
  |
  v

  If some client has seen a sucessful "commit",
  if the primary node fails,
  that commit may or may not have made it to the peer.

Of course, the real thing is a bit more complex,
there are also the "DRBD Epochs" separated by "DRBD Barriers",
which are answered by "DRBD Barrier ACKs";
neither disk latency nor network latency is constant; ...
various other things that may have impact on latency and/or bandwidth.
In short, estimating the impact on performance is not always "intuitive".

Hth,

-- 
: 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.



More information about the drbd-user mailing list