From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jyn0p-0006RF-Vt for qemu-devel@nongnu.org; Wed, 21 May 2008 08:01:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jyn0o-0006OX-GX for qemu-devel@nongnu.org; Wed, 21 May 2008 08:01:42 -0400 Received: from [199.232.76.173] (port=50837 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jyn0n-0006OG-KI for qemu-devel@nongnu.org; Wed, 21 May 2008 08:01:41 -0400 Received: from mail2.shareable.org ([80.68.89.115]:52613) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jymjf-00021t-Kd for qemu-devel@nongnu.org; Wed, 21 May 2008 07:44:00 -0400 Date: Wed, 21 May 2008 12:43:57 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH][v2] Align file accesses with cache=off (O_DIRECT) Message-ID: <20080521114357.GD12968@shareable.org> References: <1211283126.4314.70.camel@frecb07144> <48332AB9.3010707@codemonkey.ws> <20080520223602.GE27853@shareable.org> <48337444.2070203@codemonkey.ws> <20080521011915.GC595@shareable.org> <48338522.7030306@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48338522.7030306@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 Cc: Blue Swirl , Laurent Vivier , Kevin Wolf Anthony Liguori wrote: > >There is not enough residual power to write the rest of the sector. > >That sector's checksum will therefore be corrupt, and (hopefully) have > >a CRC read error. It can be written over again, wiping the CRC error. > > Why would the sector's checksum be corrupt? The checksum wouldn't > change after the data write. Changing part of the data invalidates a CRC... Also don't forget: > >This is because the way data is recorded does not encode each bit > >separately, but multiplexes them together for modulation, and also > >because bit timing is not exact. Inexact bit timing means the bits are not written exactly over the previous bits, so there's a mismatch if you abort in the middle even if all the bits are identical. Finally, some kinds of data modulation use random numbers too, to make the stored power spectrum independent of what data you are writing. > Modern *enterprise* hard disks have battery backed caches so read/write > operations always complete or fail. True. And some have flash - when the battery or capacitor is low, they can write to flash. > Low-end disks don't tend to have battery backed caches but AFAIK, > rewriting the same data will not result in any sort of disk corruption. There's only one way to find out for sure... do the tests. Or ask the manufacturers, maybe they know. Or ask Oracle, perhaps they have done these tests. -- Jamie