WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] request of blkfront may disorder after migration without

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] request of blkfront may disorder after migration without waiting in suspend phase of migration
From: alice wan <wanjia19870902@xxxxxxxxx>
Date: Wed, 13 Jul 2011 18:57:06 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 13 Jul 2011 03:58:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E0oqDUtJ+8ShQGr1trAPPYVIq6AHiz5+7h19ecShg0s=; b=EC5mItcl0dbq4cHUuuCzPZql+g4Sro/vOc2i5xNYb4NpufhrJcpLF2M5YZW4zX+8Z1 veytiwLjFFovcdhfo06aD+B5+N/BC7H3RI5/mC+yjw7XgXKtIiizimzZqIZITpc+wbXl 5KbuFK9jIYZAjo396vG230dof7uX0ZMZUC7CY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110712182335.GA24828@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CAKQ7UJnkTREkHw11_C46CTLzXwcgB_ADSGFONCMDKjPU=0nHKw@xxxxxxxxxxxxxx> <20110712182335.GA24828@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx


2011/7/13 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
On Sun, Jul 10, 2011 at 12:36:06PM +0800, alice wan wrote:
> Hi konrad,
>
> I found the mainline linux 3.0-rc6 xen-blkfront driver doesn't implement
> suspend func. In my opinion, the blkfront should wait till responses of all
> the pending requests come back, then domu can be suspended,

I think you mean blkback. It should be the job of blkback to account for
all I/Os and make sure they have completed before migrating?

I did have a patch for the 2.6.32 to deal with this but I never was able
to reproduce this. Are you able to reproduce this? Can you give me
step by step instructions on how to do it?
 
yeah,  just because i didn't see any code in blkback to waiting for IO before migrating,
blkfront's the rest one to do this job that it actively switches to Closing state, then blkback can observe it and call blkif_disconnect to account for all IO.
 
my test procedure is like this
> More, i did some test with migration,  while vm was running dd task,  xm
> migrate -l .  before it suspend, gdb tapdisk2.  after migration, new vm
> started. then quit gdb, the pending request were written back to disk after
> new requests.
 
gdb tapdisk2 , the IO of src host hanged, when xc_save did suspend, after 100s, socket was shutted down, Vm of target host resumed and continued to dd, then quit gdb.
 
this test is quite extreme. normal migration depends on whether all IO can be completed in 100s.
 
well, i need the IO have 100% safety, especially in the distributed fs.
 
of course, blkback is the best choice to ensure this.

> otherwise,  after the migration, vm of target host will request from target
> host, meanwhile, the blkback of source host maybe do the pending requests
> until they's done.
>
> if migrate the vm with high io pressure,  the requests of this vm may
> disorder.
>
> And i saw the gpl windows pv driver, blkfront will change its state and wait
> for blkback closing, after blkback closing, the pending requests definitely
> are done.
>
> More, i did some test with migration,  while vm was running dd task,  xm
> migrate -l .  before it suspend, gdb tapdisk2.  after migration, new vm
> started. then quit gdb, the pending request were written back to disk after
> new requests.
>
> above mentioned is just my opinion, i need your advice and confirmation or
> deny
>
> any help is appreciated.
>
>
> Regards
>
> wanjia

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel