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 Mon, Sep 16, 2013 at 04:50:14PM +0930, Rusty Russell wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> > Redirecting discussion to virtio-dev@lists.oasis-open.org
> > as per oasis rules.
> >
> > On Tue, Sep 10, 2013 at 05:27:26PM +0000, James Bottomley wrote:
> >> [resending to virtio-comment; it looks like I'm not subscribed to
> >> virtio-dev ... how do you subscribe?]
> >> 
> >> Sorry, I don't have a copy of the original email to reply to:
> >> 
> >> https://lists.oasis-open.org/archives/virtio-comment/201308/msg00078.html
> >> 
> >> The part that concerns me is this:
> >> 
> >> > +5. The cache mode should be read from the writeback field of the configuration
> >> > +  if the VIRTIO_BLK_F_CONFIG_WCE feature if available; the driver can also
> >> > +  write to the field in order to toggle the cache between writethrough (0)
> >> > +  and writeback (1) mode.
> >> > +  If the feature is not available, the driver can instead look at the result
> >> > +  of negotiating VIRTIO_BLK_F_WCE: the cache will be in writeback mode after
> >> > +  reset if and only if VIRTIO_BLK_F_WCE is negotiated[30]
> >> 
> >> The questions are twofold and have to do with Write Back only disks (to
> >> date we've seen quite a few ATA devices like this and a huge number of
> >> USB devices):
> >> 
> >>      1. If the guest doesn't negotiate WCE, what do you do on the host
> >>         (flush on every write is one possible option; run unsafe and
> >>         hope the host doesn't crash is another).
> >>      2. If the guest asks to toggle the device from writeback (1) to
> >>         writethrough (0) mode, what do you do?  Refuse the toggle would
> >>         be reasonable or flip back into whatever mode you were using to
> >>         handle 1. is also possible.
> >> 
> >> James
> >
> >
> > Basically if I understand what you are saying, we should
> > just require devices to make WCE state always present in config space,
> > and ask drivers to always read the value from config space
> > instead of assuming tricky logic ""the cache will be in writeback mode
> > after reset if and only if VIRTIO_BLK_F_WCE is negotiated"
> 
> 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?
> 
> So the advice would be as follows:
> Driver authors: 
>         If you want simplicity, ignore VIRTIO_BLK_F_WCE.
>         If you want performance, you should negotiate VIRTIO_BLK_F_WCE.
>                 And if you also want to expose a toggle (eg. for testing), you
>                 can negotiate VIRTIO_BLK_F_CONFIG_WCE.
> Device authors:
>         If you want simplicity, don't offer VIRTIO_BLK_F_WCE.
>         If you want performance, offer VIRTIO_BLK_F_WCE.
>                 And if you're masochistic, offer VIRTIO_BLK_F_CONFIG_WCE
>                 so they can toggle.
> 
> Cheers,
> Rusty.

Okay so IIUC with hosts which use WCE storage as the back-end, not using
WCE will basically require host to flush after each transaction.
If we resolve VIRTIO-30, hosts will be able to make WCE mandatory if
they wish.

-- 
MST


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