On Tue, Nov 30, 2010 at 9:50 AM, Yoshiaki Tamura <tamura.yoshi...@lab.ntt.co.jp> wrote: > 2010/11/29 Stefan Hajnoczi <stefa...@gmail.com>: >> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura >> <tamura.yoshi...@lab.ntt.co.jp> wrote: >>> 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 <tamura.yoshi...@lab.ntt.co.jp> >>> Signed-off-by: OHMURA Kei <ohmura....@lab.ntt.co.jp> >>> --- >>> Makefile.target | 1 + >>> block.h | 9 + >>> event-tap.c | 794 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> event-tap.h | 34 +++ >>> net.h | 4 + >>> net/queue.c | 1 + >>> 6 files changed, 843 insertions(+), 0 deletions(-) >>> create mode 100644 event-tap.c >>> create mode 100644 event-tap.h >> >> event_tap_state is checked at the beginning of several functions. If >> there is an unexpected state the function silently returns. Should >> these checks really be assert() so there is an abort and backtrace if >> the program ever reaches this state?
Fancier error handling would work too. For example cleaning up, turning off Kemari, and producing an error message with error_report(). In that case we need to think through the state of the environment carefully and make sure we don't cause secondary failures (like memory leaks). > BTW, I would like to ask a question regarding this. There is a > callback which net/block calls after processing the requests, and > is there a clean way to set this callback on the failovered > host upon replay? I think this is a limitation in the current design. If requests are re-issued by Kemari at the net/block level, how will the higher layers know about these requests? How will they be prepared to accept callbacks? Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
