From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42924 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKUhl-0007x7-9S for qemu-devel@nongnu.org; Fri, 04 Jun 2010 07:04:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKUhj-0006we-G8 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 07:04:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51325) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKUhj-0006wW-8A for qemu-devel@nongnu.org; Fri, 04 Jun 2010 07:04:47 -0400 Message-ID: <4C08DDA0.40607@redhat.com> Date: Fri, 04 Jun 2010 13:04:00 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1275014699-9431-1-git-send-email-morita.kazutaka@lab.ntt.co.jp> <1275014699-9431-4-git-send-email-morita.kazutaka@lab.ntt.co.jp> <4C0662DE.90705@redhat.com> <87632013w5.wl%morita.kazutaka@lab.ntt.co.jp> In-Reply-To: <87632013w5.wl%morita.kazutaka@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH v4 3/3] block: add sheepdog driver for distributed storage support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: MORITA Kazutaka Cc: aliguori@us.ibm.com, sheepdog@lists.wpkg.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, avi@redhat.com, hch@lst.de Am 03.06.2010 18:23, schrieb MORITA Kazutaka: >>> +static void sd_aio_cancel(BlockDriverAIOCB *blockacb) >>> +{ >>> + SheepdogAIOCB *acb = (SheepdogAIOCB *)blockacb; >>> + >>> + acb->canceled = 1; >>> +} >> >> Does this provide the right semantics? You haven't really cancelled the >> request, but you pretend to. So you actually complete the request in the >> background and then throw the return code away. >> >> I seem to remember that posix-aio-compat.c waits at this point for >> completion of the requests, calls the callbacks and only afterwards >> returns from aio_cancel when no more requests are in flight. >> >> Or if you can really cancel requests, it would be the best option, of >> course. >> > > Sheepdog cannot cancel the requests which are already sent to the > servers. So, as you say, we pretend to cancel the requests without > waiting for completion of them. However, are there any situation > where pretending to cancel causes problems in practice? I'm not sure how often it would happen in practice, but if the guest OS thinks the old value is on disk when in fact the new one is, this could lead to corruption. I think if it can happen, even without evidence that it actually does, it's already relevant enough. > To wait for completion of the requests here, we may need to create > another thread for processing I/O like posix-aio-compat.c. I don't think you need a thread to get the same behaviour, you just need to call the fd handlers like in the main loop. It would probably be the first driver doing this, though, and it's not an often used code path, so it might be a bad idea. Maybe it's reasonable to just complete the request with -EIO? This way the guest couldn't make any assumption about the data written. On the other hand, it could be unhappy about failed requests, but that's probably better than corruption. Kevin