Re: [Xen-devel] [PATCH v10] remus drbd: Implement remus drbd replicated disk

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Fri, Jun 6, 2014 at 12:38 AM, Hongyang Yang <yanghy@xxxxxxxxxxxxxx> wrote:

On 06/06/2014 02:14 AM, Shriram Rajagopalan wrote:

On Jun 5, 2014 11:11 PM, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx

<mailto:Ian.Jackson@xxxxxxxxxxcom>> wrote:
Â>
Â> Shriram Rajagopalan writes ("Re: [PATCH v10] remus drbd: Implement remus drbd
replicated disk"):
Â> > On Wed, Jun 4, 2014 at 8:39 PM, Yang Hongyang <yanghy@xxxxxxxxxxxxxx

<mailto:yanghy@xxxxxxxxxxxxxx>> wrote:
Â> > Â Â + Â Âif (ackwait) {
Â> > Â Â + Â Â Â Âioctl(rdd->ctl_fd, DRBD_WAIT_CHECKPOINT_ACK, 0);
Â> > Â Â + Â Â Â Âackwait = 0;
Â> > Â Â + Â Â}
Â> ...
Â> > Please get rid of the async execution just to execute a sys
Â> > call.
Â>
Â> Are you sure ? ÂDoes this syscall not await network traffic ?
Â>

It does. But the design is such that the disk and memory checkpoints are
simultaneously transmitted. So by the time this call is made, the ack is already
in the system.
-- this is the common case. Covers about 90% of the calls (since disk traffic is
pretty low compared to memory checkpoint).

Â> What if the network is broken ? ÂMight it not then delay indefinitely ?

Nope. ÂI designed the relevant drbd code such that the ioctl wait times out
(configurable) in worst case, returning an error. The time out is generally
about 300ms. This code path is exercised only during failures.

So, a one-time error condition and few slow checkpoints out of an indefinite
number of checkpoints don't warrant a fork per ioctl call (which usually returns
immediately).

Can we use the following approach:
 The interface for per checkpoint remains async. but in the implementation,
because the syscalls are fast enough, we can simply make it a sync call and
call the async callback when done?

Â

Yes, that should work for the fast path - which is the common case.

I know that there is no script execution.

My problem is with forking itself. Quick is a very relative term: fork may appear quick

under simple test cases, but not under moderate to heavy loads (say there are multiple

remus instances running on a host). The CPU overhead in Dom0 will no longer be

sustainable.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel