On Wed, Sep 11, 2013 at 12:49:26PM +0930, Rusty Russell wrote:
> James Bottomley <> writes:
> > [resending to virtio-comment; it looks like I'm not subscribed to
> > virtio-dev ... how do you subscribe?]
>
> Mail to , or via
> https://www.oasis-open.org/mlmanage/
>
> BTW, I've moved this to virtio@ since it's core business, with virtio-comment
> cc'd.
>
Hmm I don't think we should Cc both - this just makes most people get
two copies.
> > 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
>
> I thought about this more after the call. If we look at block device
> implementations on the host:
>
> 1) Dumb device (ie. no flush support).
> - Get write request, write() to backing file. Repeat.
> - If guest crashes it always sees in order, if host crashes you're
> out of luck.
>
> 2) Dumb device which tries to handle host crashes.
> - Noone wants this: requires a fdatasync() after every write.
>
> 3) Smart device. Uses AIO/threads to service requests.
> - Needs flushes otherwise if guest crashes it can see out of order.
> - Flushes can must wait for outstanding requests.
>
> 4) Smart device which tries to handle host crashes.
> - Flushes must fdatasync() after waiting.
>
> The interesting question is between 3 & 4:
> - Do we differentiate 3 and 4 from the guest side?
> - Or do we ban 3 and insist on 4? Knowing that there are no guarantees that an
> implementation will actually hit the metal (eg. crappy underlying
> device or crappy non-barrier filesystem).
>
> Whatever we do, I don't see why we'd want to toggle WCE after
> negotiation.
I think it's mostly because sdparm let you tweak it for normal disks ...
> If you implement a smart device, you'd need to drop to a
> single thread, but you'd definitely lose host-crash reliability.
>
> Cheers,
> Rusty.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
