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