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

[Rusty Russell <rusty@au1.ibm.com>]

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.

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

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.