From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTa2Q-00058J-Pp for qemu-devel@nongnu.org; Thu, 14 Aug 2008 06:26:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTa2P-00057B-Qw for qemu-devel@nongnu.org; Thu, 14 Aug 2008 06:26:38 -0400 Received: from [199.232.76.173] (port=37303 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTa2P-00056z-Ez for qemu-devel@nongnu.org; Thu, 14 Aug 2008 06:26:37 -0400 Received: from mail2.shareable.org ([80.68.89.115]:33129) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KTa2O-0000q4-AS for qemu-devel@nongnu.org; Thu, 14 Aug 2008 06:26:36 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KTa2N-0000Tz-5W for qemu-devel@nongnu.org; Thu, 14 Aug 2008 11:26:35 +0100 Date: Thu, 14 Aug 2008 11:26:35 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Flush pending AIO on reboot and shutdown. Message-ID: <20080814102635.GD682@shareable.org> 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> <48A32AA2.6030902@qumranet.com> <20080813185339.GB29998@minantech.com> <48A33057.6010207@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A33057.6010207@codemonkey.ws> 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 Anthony Liguori wrote: > Gleb Natapov wrote: > >On Wed, Aug 13, 2008 at 09:40:34PM +0300, Avi Kivity wrote: > > > >>Gleb Natapov wrote: > >> > >>>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. > >>> > >>> > >>> > >>If a guest didn't wait for an I/O to complete, it shouldn't expect it to > >>be on disk. > >> > >If you'll save your swiss bank account details in file and suddenly > >your guest will crash, you'll surely appreciate if qemu will save it > >for you :) > > > > > >>Of course, we can have the IDE layer wait instead of cancelling, which > >>will get the request onto the disk. > >> > >> > >That is the current approach, but the wait is done for all block IO not > >just IDE. > > > > If the guest hasn't seen confirmation that the data is on disk, as far > as the guest is concerned, it's not on disk. > > If you have a journalled file system, for instance, unless it receives > that notification, it's going to replay whatever has happened in the > journal since the last successful write operation. Practically > speaking, I don't think you're saving data. Except for old guests. Old guests don't have journalled filesystems and use the "pray it works" method. With old hardware it generally does work, with newer hardware its a bit less reliable. E.g. old disks and old BIOSes don't enable disk write cache, and old guests don't know anything about it. -- Jamie