[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




On Jun 5, 2014 11:11 PM, "Ian Jackson" <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> 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).

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

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.