All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	Rusty Russell <rusty@rustcorp.com.au>,
	kvm@vger.kernel.org
Subject: Re: [PATCH, RFC] virtio_blk: add cache flush command
Date: Tue, 12 May 2009 11:35:23 +0300	[thread overview]
Message-ID: <4A0934CB.1000601@redhat.com> (raw)
In-Reply-To: <20090512071950.GA5627@lst.de>

Christoph Hellwig wrote:
> On Mon, May 11, 2009 at 07:49:37PM +0300, Avi Kivity wrote:
>   
>> Maybe we should add a fourth cache= mode then.  But 
>> cache=writeback+fsync doesn't correspond to any real world drive; in the 
>> real world you're limited to power failures and a few megabytes of cache 
>> (typically less), cache=writeback+fsync can lose hundreds of megabytes 
>> due to power loss or software failure.
>>     
>
> cache=writeback+fsync is exactly the same model as a normal writeback
> cache disk drive.  (Well, almost as we currently don't use tag ordering
> but drain flushes as a Linux implementation detail, but the disks also
> support TCQ-based ordering).
>
> The cache size on disks is constantly growing, and if you lose cache
> it doesn't really matter how much you lose but what you lose.
>   

Software errors won't cause data loss on a real disk (firmware bugs 
will, but the firmware is less likely to crash than the host OS).

>> Oh, and cache=writeback+fsync doesn't work on qcow2, unless we add fsync 
>> after metadata updates.
>>     
>
> If you care about data integrity in case of crashes qcow2 doesn't work
> at all.
>   

Do you known of any known corruptors in qcow2 with cache=writethrough?

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2009-05-12  8:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11  8:39 [PATCH, RFC] virtio_blk: add cache flush command Christoph Hellwig
2009-05-11 14:51 ` Anthony Liguori
2009-05-11 15:40   ` Christoph Hellwig
2009-05-11 15:45     ` Avi Kivity
2009-05-11 16:28       ` Christoph Hellwig
2009-05-11 16:49         ` Avi Kivity
2009-05-11 17:47           ` Anthony Liguori
2009-05-11 18:00             ` Avi Kivity
2009-05-11 18:29               ` Anthony Liguori
2009-05-11 18:40                 ` Avi Kivity
2009-05-18 12:03                 ` Christoph Hellwig
2009-05-12  7:23             ` Christoph Hellwig
2009-05-12  7:19           ` Christoph Hellwig
2009-05-12  8:35             ` Avi Kivity [this message]
2009-05-18 12:06               ` Christoph Hellwig
2009-05-11 16:38     ` Anthony Liguori
2009-05-12  7:26       ` Christoph Hellwig
2009-05-12 13:54 ` Rusty Russell
2009-05-12 14:18   ` Christian Borntraeger
2009-05-13  1:52     ` Rusty Russell
2009-05-18 12:07     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A0934CB.1000601@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=hch@lst.de \
    --cc=kvm@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.