Re: [PATCH, RFC] virtio_blk: add cache flush command

Avi Kivity
2009-05-11T18:41:22Z

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>
>>>
>>> Right now, it's fairly easy to understand. cache=none and
>>> cache=writethrough guarantee that all write operations that the
>>> guest thinks have completed are completed. cache=writeback provides
>>> no such guarantee.
>>
>> cache=none is partially broken as well, since O_DIRECT writes might
>> hit an un-battery-packed write cache. I think cache=writeback will
>> send the necessary flushes, if the disk and the underlying filesystem
>> support them.
>
> Sure, but this likely doesn't upset people that much since O_DIRECT
> has always had this behavior.

But people are not using O_DIRECT. They're using their guests, which
may or may not issue the appropriate barriers. They don't know that
we're using O_DIRECT underneath with different guarantees.

> Using non-battery backed disks with writeback enabled introduces a
> larger set of possible data integrity issues. I think this case is
> acceptable to ignore because it's a straight forward policy.

It isn't straightforward to me. A guest should be able to get the same
guarantees running on a hypervisor backed by such a disk as it would get
if it was running on bare metal with the same disk. Right now, that's
not the case, we're reducing the guarantees the guest gets.

>>> cache=writeback+fsync would guarantee that only operations that
>>> include a T_FLUSH are present on disk which currently includes
>>> fsyncs but does not include O_DIRECT writes. I guess whether O_SYNC
>>> does a T_FLUSH also has to be determined.
>>>
>>> It seems too complicated to me. If we could provide a mode where
>>> cache=writeback provided as strong a guarantee as
>>> cache=writethrough, then that would be quite interesting.
>>
>> It don't think we realistically can.
>
> Maybe two fds? One open in O_SYNC and one not. Is such a thing sane?

For all I care, yes. Filesystem developers would probably have you
locked up.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.