From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [PATCH v10] remus drbd: Implement remus drbd
	replicated disk
Date: Fri, 6 Jun 2014 13:38:31 +0800
Message-ID: <539153D7.2030707@cn.fujitsu.com>
References: <1401932069-16460-6-git-send-email-yanghy@cn.fujitsu.com>	<1401932386-16538-1-git-send-email-yanghy@cn.fujitsu.com>	<CAP8mzPNaquHkXG6-mVXrE+EpMOaVjCTWzWhf0=kFXbfmKu-epQ@mail.gmail.com>	<21392.43961.872654.69939@mariner.uk.xensource.com>
	<CAP8mzPNAVGjiesyHaHV-yqpC3X+cn4n8VCq+ZAbE+x5fPc+RVw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAP8mzPNAVGjiesyHaHV-yqpC3X+cn4n8VCq+ZAbE+x5fPc+RVw@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: rshriram@cs.ubc.ca, Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Wen Congyang <wency@cn.fujitsu.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>, =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 06/06/2014 02:14 AM, Shriram Rajagopalan wrote:
>
> On Jun 5, 2014 11:11 PM, "Ian Jackson" <Ian.Jackson@eu.citrix.com
> <mailto:Ian.Jackson@eu.citrix.com>> 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@cn.fujitsu.com
> <mailto:yanghy@cn.fujitsu.com>> 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.