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

[Avi Kivity <avi@redhat.com>]

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.