[PATCH 09/18] Introduce event-tap.

event-tap controls when to start FT transaction, and provides proxy functions to called from net/block devices. While FT transaction, it queues up net/block requests, and flush them when the transaction gets completed. Signed-off-by: Yoshiaki Tamura Signed-off-by: OHMURA Kei --- Makefile.targe

[PATCH 09/18] Introduce event-tap.

event-tap controls when to start FT transaction, and provides proxy functions to called from net/block devices. While FT transaction, it queues up net/block requests, and flush them when the transaction gets completed. Signed-off-by: Yoshiaki Tamura Signed-off-by: OHMURA Kei --- Makefile.targe

[PATCH 09/18] Introduce event-tap.

event-tap controls when to start FT transaction, and provides proxy functions to called from net/block devices. While FT transaction, it queues up net/block requests, and flush them when the transaction gets completed. Signed-off-by: Yoshiaki Tamura Signed-off-by: OHMURA Kei --- Makefile.targe

[PATCH 09/18] Introduce event-tap.

event-tap controls when to start FT transaction, and provides proxy functions to called from net/block devices. While FT transaction, it queues up net/block requests, and flush them when the transaction gets completed. Signed-off-by: Yoshiaki Tamura Signed-off-by: OHMURA Kei --- Makefile.targe

[PATCH 09/18] Introduce event-tap.

event-tap controls when to start FT transaction, and provides proxy functions to called from net/block devices. While FT transaction, it queues up net/block requests, and flush them when the transaction gets completed. Signed-off-by: OHMURA Kei Signed-off-by: Yoshiaki Tamura --- Makefile.targe

Re: [PATCH 09/18] Introduce event-tap.

Yokshiaki: event-tap record block and io wirte events, and replay these on the other side, so block_save_live is useless during the latter ft phase, right? if so, I think it need to process the following code in block_save_live function: if (stage == 1) { init_blk_migration(mon, f

Re: [PATCH 09/18] Introduce event-tap.

ya su wrote: Yokshiaki: event-tap record block and io wirte events, and replay these on the other side, so block_save_live is useless during the latter ft phase, right? if so, I think it need to process the following code in block_save_live function: Actually no. It just replays the last

Re: [PATCH 09/18] Introduce event-tap.

2011/3/8 Yoshiaki Tamura : > ya su wrote: >> >> Yokshiaki: >> >>     event-tap record block and io wirte events, and replay these on >> the other side, so block_save_live is useless during the latter ft >> phase, right? if so, I think it need to process the following code in >> block_save_live func

Re: [PATCH 09/18] Introduce event-tap.

Yoshi: I think event-tap is a great idea, it remove the reading from disk which will increase ft effiency much better as your plan in later series. one question: IO read/write may dirty rams, but it is difficute to differ them from other dirty pages like caused by running of softwares,

Re: [PATCH 09/18] Introduce event-tap.

ya su wrote: Yoshi: I think event-tap is a great idea, it remove the reading from disk which will increase ft effiency much better as your plan in later series. one question: IO read/write may dirty rams, but it is difficute to differ them from other dirty pages like caused by runnin

Re: [PATCH 09/18] Introduce event-tap.

Yoshi: I meet one problem if I killed a ft source VM, the dest ft VM will return errors as the following: qemu-system-x86_64: fill buffer failed, Resource temporarily unavailable qemu-system-x86_64: recv header failed the problem is that the dest VM can not continue to run, as it is inte

Re: [PATCH 09/18] Introduce event-tap.

ya su wrote: Yoshi: I meet one problem if I killed a ft source VM, the dest ft VM will return errors as the following: qemu-system-x86_64: fill buffer failed, Resource temporarily unavailable qemu-system-x86_64: recv header failed the problem is that the dest VM can not continue to r