From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLIn4-0005t4-2n for qemu-devel@nongnu.org; Tue, 22 Jul 2008 10:24:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLIn2-0005sp-Kc for qemu-devel@nongnu.org; Tue, 22 Jul 2008 10:24:33 -0400 Received: from [199.232.76.173] (port=39026 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLIn2-0005sm-FQ for qemu-devel@nongnu.org; Tue, 22 Jul 2008 10:24:32 -0400 Received: from mail2.shareable.org ([80.68.89.115]:38170) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KLIn2-0000oQ-5s for qemu-devel@nongnu.org; Tue, 22 Jul 2008 10:24:32 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KLJ8Y-0005bX-KN for qemu-devel@nongnu.org; Tue, 22 Jul 2008 15:46:46 +0100 Date: Tue, 22 Jul 2008 15:46:46 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail? Message-ID: <20080722144646.GD20829@shareable.org> References: <47CF0E0C.9030807@quinthar.com> <47CF16C5.6040102@codemonkey.ws> <20080721181031.GA31773@shareable.org> <4884E6F1.5020205@codemonkey.ws> <20080721212604.GA2823@shareable.org> <48850A5A.3070106@codemonkey.ws> <488578CA.4000402@qumranet.com> <4885E9C2.9080209@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4885E9C2.9080209@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: > >What about SCSI or SATA NCQ? On these, barriers don't impact > >performance greatly. > > Good question, I don't know the answer. But ext3 doesn't autodetect > SCSI/NCQ or anything. It disabled barriers by default. Some distros > have changed this behavior historically (SLES I believe). Also don't forget XFS, Reiserfs. I think they both use barriers by default and have a correct fsync too. SCSI/NCQ are detected by the block layer, as long as the filesystem uses barriers. Oh, and as long as not using LVM which doesn't pass on barriers :/ > >>This is very hard to see happen in practice though because these > >>windows are very small--just like with QEMU. > > >The exposure window with qemu is not small. It's as large as the page > >cache of the host. > > Note I was careful to qualify my statements that cache=off was required. Fair point. Unfortunately cache=off introduces other exposure windows. With cache=on, the multiple block writes to allocate a qcow2 sector are in fast succession, so a QEMU crash (or signal) has to happen during this short interval. With cache=off, those writes will take as long as the disk seeks between them, so there's a longer time window for a QEMU crash to corrupt the file. Also with cache=off, there's no disk barriers on any filesystem and any filesystem options, so there's the additional time window of disk cache inconsistency with the platters. Databases face the same problem on Linux, but it's often ignored. Does anyone know what Oracle on Linux does to keep it's structures robust? -- Jamie