From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51457 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBsxi-0001HP-OT for qemu-devel@nongnu.org; Tue, 11 May 2010 13:09:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBsxT-0006dQ-VM for qemu-devel@nongnu.org; Tue, 11 May 2010 13:09:36 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:65419) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBsxN-0006Vi-4a for qemu-devel@nongnu.org; Tue, 11 May 2010 13:09:25 -0400 Received: by gyd5 with SMTP id 5so2751954gyd.4 for ; Tue, 11 May 2010 10:09:20 -0700 (PDT) Message-ID: <4BE98F3A.3020503@codemonkey.ws> Date: Tue, 11 May 2010 12:09:14 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive References: <1273528310-7051-1-git-send-email-agraf@suse.de> <201005111450.53273.paul@codesourcery.com> <4BE97A58.2070907@codemonkey.ws> <201005111653.53208.paul@codesourcery.com> In-Reply-To: <201005111653.53208.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Kevin Wolf , armbru@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Christoph Hellwig On 05/11/2010 10:53 AM, Paul Brook wrote: >>> I disagree. We should not be removing or rejecting features just because >>> they allow you to shoot yourself in the foot. We probably shouldn't be >>> enabling them by default, but that's a whole different question. >>> >> I disagree and think the mentality severely hurts usability. QEMU's >> role should be to enable features, not to simplify every obscure >> feature. In general, if someone wants to accomplish something, we >> should try to provide a mechanism to accomplish it. >> cache=none|writeback|writethrough is an example of this. No one other >> than QEMU can control how we open a file descriptor so we need to >> provide a knob for it. >> > Doesn't the same argument apply to the existing cache=writethrough? > i.e. if you want to avoid data loss you should make sure your guest issues > flushes properly, and it's not something qemu should be trying to hack round > be adding an implicit flushe after every write. > cache is the host page cache acting as an extended disk cache. In writethrough mode, the behavior is identical to writethrough on a normal disk cache in that all operations are completed only when sent down to the next storage layer. In writeback mode, you rely on the integrity of the host page cache to prevent data loss. Data loss is different than data corruption though. In neither mode will a correct application experience data corruption because if a guest issues a flush, we respect those requests. However, the new proposed mode would introduce the possibility of data corruption because it becomes possible for writes to be written to disk outside the order requested by the guest. In the event of power loss, the result is corruption. Regards, Anthony Liguori > Paul >