From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCpiC-0004VW-3y for qemu-devel@nongnu.org; Thu, 21 Apr 2011 04:58:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCpiA-0000bl-QO for qemu-devel@nongnu.org; Thu, 21 Apr 2011 04:58:08 -0400 Received: from mail-vx0-f173.google.com ([209.85.220.173]:33699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCpiA-0000ba-EO for qemu-devel@nongnu.org; Thu, 21 Apr 2011 04:58:06 -0400 Received: by vxb41 with SMTP id 41so1277982vxb.4 for ; Thu, 21 Apr 2011 01:58:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110421085026.GA4817@lst.de> References: <1303375391-26679-1-git-send-email-ronniesahlberg@gmail.com> <20110421085026.GA4817@lst.de> Date: Thu, 21 Apr 2011 18:58:05 +1000 Message-ID: From: ronnie sahlberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] iSCSI support for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Please re-read my post or read the patch. It has O_DIRECT like behaviour in that it will not pollute the hosts cache. This for the simple reason that the host is not aware that there is any block i/o happening. In my patch, there are NO data integrity issues. Data is sent out on the wire immediately as the guest issues the write. Once the guest issues a flush call, the flush call will not terminate until the SYNCCACHE10 task has completed. I do not have any cache at all in libiscsi or the patch. All I/O are always sent to the iSCSI target. No data is ever cached anywhere. I am just saying that in the tests I did, I had to use 'cache=3Dnone,aio=3Dnative' to come anywhere near the libiscsi performance. All other options performed significantly worse. I have no idea what those options have for effect on data integrity or open-iscsi. There should not be any integrity issues in libiscsi since it does not cache at all, ever. regards ronnie sahlberg On Thu, Apr 21, 2011 at 6:50 PM, Christoph Hellwig wrote: > On Thu, Apr 21, 2011 at 06:43:10PM +1000, Ronnie Sahlberg wrote: >> Some basic tests thatve been performed show it to be significantly faste= r >> than an out-of-the-box open-iscsi mounted LUN being accessed by default >> QEMU i/o options. > > Which isn't a useful comparism. =A0qemu's default is the braindead > cache=3Dwritethrough behaviour, which forces writes out to disk, and bloa= ts the > pagecache, while your mail sounds you silently always implement O_DIRECT-= like > semantics. > > Also the implementation has data integrity issues due this. =A0It does > not actually force writes out to disk in the default cache mode, despite > qemu claiming to have WCE=3D0 in the default mode, i.e. you never flush > the cache. =A0You'll need set the FUA bits on all writes if cache=3Dwrite= through > is used, with a fallback to a real cache flush in case the target doesn't > support the FUA bit. > >