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.
> 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. 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.
