From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6ZDC-0007ZF-Di for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:45:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6ZDA-0007Yf-Ta for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:45:34 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6ZDA-0007Yc-OW for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:45:32 -0400 Received: from [66.187.233.31] (helo=mx1.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6ZFE-0002TH-K6 for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:47:40 -0400 Message-ID: <44CA76E6.4050702@redhat.com> Date: Fri, 28 Jul 2006 16:43:18 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk References: <44CA6B76.7000004@redhat.com> <44CA7102.1020402@redhat.com> <200607282130.11255.paul@codesourcery.com> In-Reply-To: <200607282130.11255.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: alan@redhat.com, qemu-devel@nongnu.org Paul Brook wrote: >>> With a proper async API, is there any reason why we would want this to be >>> tunable? I don't think there's much of a benefit of prematurely claiming >>> a write is complete especially once the SCSI emulation can support >>> multiple simultaneous requests. >> You're right. This O_SYNC bandaid should probably stay in place >> to prevent data corruption, until the AIO framework is ready to >> be used. > > It's arguable whether O_SYNC is needed at all. Qemu doesn't claim data is > written to disk, and provides facilities for the guest OS to flush the cache, > just like real hardware does. Nice. Another difference between the qemu codebase and the qemu-dm codebase used by Xen. With the bdrv_flush stuff in place, it should even be easy for qemu to actually do something when the guest OS switches disk write caching off (currently that is a noop in the qemu code base). > Have you measured the impact of O_SYNC? I wouldn't be surprised if it was > significant. I suspect it'll be horrific in the qemu codebase (blocking execution of the guest OS until disk IO is complete), but it's fine in the Xen qemu-dm situation, where IO completion happens asynchronously. The recent commit message on the Xen side did not suggest there was that much of a difference between both qemu code bases. Obviously I was wrong, and the O_SYNC bandaid should probably be kept out for now. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan