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.