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

[Hongyang Yang <yanghy@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx>> 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?

>  >
>  > > Not to mention a fork & exec per sys call,
>  >
>  > In fact there is no exec, only a fork.
>  >
>  > Ian.
>  >
--
Thanks,
Yang.

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