On 02/07/2015 10:48, Michael S. Tsirkin wrote:
>> >
>> > The above footnote is a consequence of the conformance statements in the
>> > "Device Operation" section. (Hence putting it in a footnote only).
> Hmm I don't get it.
>
> The only non-legacy text that mention writethrough is this:
> VIRTIO_BLK_F_CONFIG_WCE (11) Device can toggle its cache between
> writeback and writethrough modes.
>
> so this is the only definition of these terms.
After the patch (quoting from v2):
+If the VIRTIO_BLK_F_CONFIG_WCE feature is negotiated and the
+\field{writeback} field in configuration space is 0, the device MUST
+ensure that all writes are committed to non-volatile storage before
+reporting completion.
+
+If the VIRTIO_BLK_F_CONFIG_WCE feature is negotiated, the driver MAY
+switch to writethrough or writeback mode by writing respectively 0 and
+1 to the \field{writeback} field. After writing a 0 to \field{writeback},
+the driver MUST NOT assume that writes submitted while the field was 1 have
+been committed to non-volatile storage.
> Also, isn't the flush command special in the writeback mode?
> maybe mention this...
Again quoting from v2:
+If the \field{VIRTIO_BLK_F_FLUSH} feature is negotiated, upon receipt
+of a VIRTIO_BLK_T_FLUSH request, the device MUST ensure that any writes
+which were completed are committed to non-volatile storage.
>
> Also
> Some older legacy devices did not operate in writethrough mode
> even after a driver announced lack of
> support for VIRTIO_BLK_F_FLUSH.
>
> What does this mean? let's just say in which mode they did operate.
> Also what should driver do in this case?
In v2:
+If the \field{VIRTIO_BLK_F_FLUSH} feature is not negotiated, the
+device SHOULD ensure that all writes are committed to non-volatile
+storage before reporting completion. It MUST do so if it proposed
+\field{VIRTIO_BLK_F_FLUSH}. Failure to do so can cause data loss.
(No humor intended, I know this is not your field of expertise).
Paolo
