qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Notes on block I/O data integrity


From: Rusty Russell
Subject: [Qemu-devel] Re: Notes on block I/O data integrity
Date: Fri, 28 Aug 2009 11:33:59 +0930
User-agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; )

On Thu, 27 Aug 2009 11:12:39 pm Christoph Hellwig wrote:
> On Thu, Aug 27, 2009 at 08:21:55PM +0930, Rusty Russell wrote:
> > >  - virtio-blk needs to advertise ordered queue by default.
> > >    This makes cache=writethrough safe on virtio.
> > 
> > >From a guest POV, that's "we don't know, let's say we're ordered because 
> > >that
> > may make us safer".  Of course, it may not help: how much does it cost to
> > drain the queue?
> > 
> > The bug, IMHO is that we *should* know.  And in future I'd like to fix that,
> > either by adding an VIRTIO_BLK_F_ORDERED feature, or a 
> > VIRTIO_BLK_F_UNORDERED
> > feature.
> > 
> > > Action plan for QEMU:
> > > 
> > >  - IDE needs to set the write cache enabled bit
> > >  - virtio needs to implement a cache flush command and advertise it
> > >    (also needs a small change to the host driver)
> > 
> > So, virtio-blk needs to be enhanced for this as well.
> 
> Really, enabling volatile write caches without advertising a cache flush
> command is a bug in the storage, where in our case qemu is the storage.
> So I don't really see the need for two feature bits.  Here's my plan for
> virtio-blk:
> 
>  - add a new VIRTIO_BLK_F_WCACHE feature.  If this feature is set we
>    do
>      (a) implement the prepare_flush queue operation to send a
>          standalone cache flush
>      (b) set a proper barrier ordering flag on the queue

OK, I buy that.  I'll update the virtio_pci spec accordingly, too.

I've applied your previous patch.

> The complex (not to say over engineered) verison would be to split
> the caching and data integrity setting into two options:
> 
>  (1) hostcache=on|off
>       use buffered vs O_DIRECT I/O
>  (2) integrity=osync|fsync|none
>       use O_SYNC, use f(data)sync or do not care about data integrity

If we were starting from scratch, I'd agree.  But seems like too much
user-visible churn.

Thanks,
Rusty.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]