From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTLdY-0002ZX-9c for qemu-devel@nongnu.org; Wed, 13 Aug 2008 15:04:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTLdV-0002WQ-OA for qemu-devel@nongnu.org; Wed, 13 Aug 2008 15:03:59 -0400 Received: from [199.232.76.173] (port=56711 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTLdV-0002W7-Il for qemu-devel@nongnu.org; Wed, 13 Aug 2008 15:03:57 -0400 Received: from mail-gx0-f23.google.com ([209.85.217.23]:56260) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTLdT-0001ss-Nl for qemu-devel@nongnu.org; Wed, 13 Aug 2008 15:03:57 -0400 Received: by gxk4 with SMTP id 4so1414377gxk.10 for ; Wed, 13 Aug 2008 12:03:51 -0700 (PDT) Message-ID: <48A32FF1.5040302@codemonkey.ws> Date: Wed, 13 Aug 2008 14:03:13 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Flush pending AIO on reboot and shutdown. References: <20080813132358.17672.68212.stgit@gleb-debian.qumranet.com.qumranet.com> <48A2E732.4040501@codemonkey.ws> <20080813141346.GC17567@minantech.com> <48A2F89A.20609@codemonkey.ws> <20080813152329.GG17567@minantech.com> <48A30395.6060706@codemonkey.ws> <20080813183544.GA29998@minantech.com> In-Reply-To: <20080813183544.GA29998@minantech.com> Content-Type: text/plain; charset=ISO-8859-1; 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: qemu-devel@nongnu.org Gleb Natapov wrote: > On Wed, Aug 13, 2008 at 10:53:57AM -0500, Anthony Liguori wrote: > >> Now that I think about it, I think your fixing the wrong problem. The >> issue isn't that the IO requests need to be completed, but that they >> *will* complete which means that the IDE driver will receive a callback >> for a request that it no longer knows about (because it was reset). So >> > Not exactly. IDE still knows about the request after reset (actually currently > IDE doesn't know about reset), but the IDE code is written in such a way that > there can be only one outstanding request in progress. When guest issues > another request before previous request is completed global data is > modified and first request start to use wrong data and consequences are > unpredictable. It may be crash, image corruption, infinity recursion. > The fact that IDE code allows to issue another request wile IDE is still > busy is also a bug. > Yeah, let's fix this properly. I worry that this could be a DoS on the part of the guest (or even worse). >> what we really need to do is modify the IDE device such that when it is >> reset, it cancels any pending requests. >> >> The fact that this reset happens as a consequence of a system reset is >> really just a coincidence. >> > That will also solve the problem of cause, but what bother me is that we > consciously drop user data that we can easily save. Why? Real HW tries > hard to save every bit of user data and we just decided to drop it. The > difference between cancel or complete a request may be corrupted or not > corrupted file system after a crash. > I don't think of this as "saving user data". From the guest's perspective, data is only written to disk after a write completion has be issued. I think it's worse for data to end up being written to disk without that completion ever being seen by the guest. Regards, Anthony Liguori > I'll send updated patch. > > -- > Gleb. > > >