OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Re: [virtio-comment] Problems with VIRTIO-4 and writeback only disks


On Tue, Sep 17, 2013 at 03:03:47PM +0930, Rusty Russell wrote:
> James Bottomley <jbottomley@parallels.com> writes:
> > On Mon, 2013-09-16 at 16:50 +0930, Rusty Russell wrote:
> >> I think we should do the reverse:
> >> 1) If you negotiate VIRTIO_BLK_F_WCE, you need to flush (ie. it's
> >>    writeback).  Otherwise it's write-through.
> >> 2) If (and only if) you negotiate VIRTIO_BLK_F_WCE, you may also negotiate
> >>    VIRTIO_BLK_F_CONFIG_WCE, in which case you can toggle it.
> >> 
> >> But I'm not convinced that #2 should exist at all.  Does someone have a
> >> real use case?
> >
> > There is no use case in Linux.  We provide knobs to toggle the cache
> > type in the SCSI disk class, but the kernel doesn't do it by default, it
> > just runs with the cache type because the toggle can be unreliable.
> 
> OK.  How about this as a strawman:
> 
> 1) Kill VIRTIO_BLK_F_CONFIG_WCE as a bad idea.  You either negotiate
>    WCE or not during device setup; no toggling.

It's not really useful as guest-controlled, I agree.
But I have this vague idea:
- host wants to enable WCE on backend
- host notifies guest
- guest enables WCE
- host can now enable WCE on backend

> 2) If device offers VIRTIO_BLK_F_WCE, and driver negotiates it:
>    - Completed writes should be persistent if guest crashes.
>    - No ordering guarantees are given except where flush command sent.
>    - Flush SHOULD push all preceeding writes to permanent storage.
>      (in the RFC SHOULD sense, which is weaker than MUST).

We can also document that it's legal for device to
make the feature required (using the new handshake).


> 3) If device does not offer VIRTIO_BLK_F_WCE, or driver doesn't
>    negotiate it:
>    - Completed writes should be persistent if guest crashes.
>    - No flush commands are supported.
>    - No guarantee about writes hitting permanent storage.
> 
> This pretty neatly divides it into complex and simple cases.  If you
> want more fine-grained, you know where to find virtio-scsi...
> 
> Cheers,
> Rusty.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]