From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KL2Xw-00045H-Ic for qemu-devel@nongnu.org; Mon, 21 Jul 2008 17:03:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KL2Xu-000421-UU for qemu-devel@nongnu.org; Mon, 21 Jul 2008 17:03:52 -0400 Received: from [199.232.76.173] (port=34337 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KL2Xu-00041b-LP for qemu-devel@nongnu.org; Mon, 21 Jul 2008 17:03:50 -0400 Received: from mail2.shareable.org ([80.68.89.115]:39479) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KL2Xu-0003G4-6A for qemu-devel@nongnu.org; Mon, 21 Jul 2008 17:03:50 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KL2tQ-0000qJ-Ax for qemu-devel@nongnu.org; Mon, 21 Jul 2008 22:26:04 +0100 Date: Mon, 21 Jul 2008 22:26:04 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail? Message-ID: <20080721212604.GA2823@shareable.org> References: <47CF0E0C.9030807@quinthar.com> <47CF16C5.6040102@codemonkey.ws> <20080721181031.GA31773@shareable.org> <4884E6F1.5020205@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4884E6F1.5020205@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: > Since your guest probably is using a journalled file system, you will be > okay if something happens before that data gets written to disk[1]. Thanks Anthony, that's helpful. > If the sector hasn't been previously allocated, then a new sector in the > file needs to be allocated. This is going to change metadata within the > QCOW2 file and this is where it is possible to corrupt a disk image. > The operation of allocating a new disk sector is completely synchronous > so no other code runs until this completes. Once the disk sector is > allocated, you're safe again[1]. My main concern is corruption of the QCOW2 sector allocation map, and subsequently QEMU/KVM breaking or going wildly haywire with that file. With a normal filesystem, sure, there are lots of ways to get corruption when certain events happen. But you don't lose the _whole_ filesystem. My concern is that if the QCOW2 sector allocation map is corrupted by these events, you may lose the _whole_ virtual machine, which can be a pretty big loss. Is the format robust enough to prevent that from being a problem? (Backups help (but not good enough for things like a mail or database server). But how do you safely backup the image of a VM that is running 24x7? LVM snapshots are the only way I've thought of, and they have a barrier problem, see below.) > you have a file system that supports barriers and barriers > are enabled by default (they aren't enabled by default with ext2/3) There was recent talk of enabling them by default for ext3. > you are running QEMU with cache=off to disable host write caching. Doesn't that use O_DIRECT? O_DIRECT writes don't use barriers, and fsync() does not deterministically issue a disk barrier if there's no metadata change, so O_DIRECT writes are _less_ safe with disks which have write-cache enabled than using normal writes. What about using a partition, such as an LVM volume (so it can be snapshotted without having to take down the VM)? I'm under the impression there is no way to issue disk barrier flushes to a partition, so that's screwed too. (Besides, LVM doesn't propagate barrier requests from filesystems either...) The last two paragraphs apply when using _any_ file format and break the integrity of guest journalling filesystems, not just qcow2. > Since no other code runs during this period, bugs in the device > emulation, a user closing the SDL window, and issuing quit in the > monitor, will not corrupt the disk image. Your guest may require an > fsck but the QCOW2 image will be fine. Does this apply to KVM as well? I thought KVM had a separate threads for I/O, so problems in another subsystem might crash an I/O thread in mid action. Is that work in progress? Thanks again, -- Jamie