[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]