From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmLGR-0007BG-G5 for qemu-devel@nongnu.org; Thu, 28 Jul 2011 03:44:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmLGQ-0005DM-Gj for qemu-devel@nongnu.org; Thu, 28 Jul 2011 03:44:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmLGQ-0005DI-5n for qemu-devel@nongnu.org; Thu, 28 Jul 2011 03:44:14 -0400 Message-ID: <4E3113F9.9090902@redhat.com> Date: Thu, 28 Jul 2011 09:47:05 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1311791126-11383-1-git-send-email-freddy77@gmail.com> <1311791126-11383-2-git-send-email-freddy77@gmail.com> <20110727183122.GA14736@lst.de> <77083DC7-E37C-4B44-9A59-DB19E34D20E2@gmail.com> <20110727195718.GA16212@lst.de> In-Reply-To: <20110727195718.GA16212@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] linux aio: support flush operation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Frediano Ziglio , "qemu-devel@nongnu.org" Am 27.07.2011 21:57, schrieb Christoph Hellwig: > On Wed, Jul 27, 2011 at 09:52:51PM +0200, Frediano Ziglio wrote: >> Also I notice that combining XFS, Linux AIO, O_DIRECT and O_DSYNC give impressive performance but currently there is no way to specify all that flags together cause nocache enable O_DIRECT while O_DSYNC is enabled with writethrough. > > Indeed. This has come up a few times, and actually is a mostly trivial > task. Maybe we should give up waiting for -blockdev and separate cache > mode settings and allow a nocache-writethrough or similar mode now? It's > going to be around 10 lines of code + documentation. I understand that there may be reasons for using O_DIRECT | O_DSYNC, but what is the explanation for O_DSYNC improving performance? Christoph, on another note: Can we rely on Linux AIO never returning short writes except on EOF? Currently we return -EINVAL in this case, so I hope it's true or we wouldn't return the correct error code. The reason why I'm asking is because I want to allow reads across EOF for growable images and pad with zeros (the synchronous code does this today in order to allow bdrv_pread/pwrite to work, and when we start using coroutines in the block layer, these cases will hit the AIO paths). Kevin