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

Anthony Liguori
2009-05-11T17:48:01Z

Avi Kivity wrote:
> Christoph Hellwig wrote:
>> On Mon, May 11, 2009 at 06:45:50PM +0300, Avi Kivity wrote:
>>
>>>> Right now it's fsync. By the time I'll submit the backend change it
>>>> will still be fsync, but at least called from the posix-aio-compat
>>>> thread pool.
>>>>
>>>>
>>> I think if we have cache=writeback we should ignore this.
>>>
>>
>> It's only needed for cache=writeback, because without that there is no
>> reason to flush a write cache.
>>
>
> Maybe we should add a fourth cache= mode then. But
> cache=writeback+fsync doesn't correspond to any real world drive; in
> the real world you're limited to power failures and a few megabytes of
> cache (typically less), cache=writeback+fsync can lose hundreds of
> megabytes due to power loss or software failure.
>
> Oh, and cache=writeback+fsync doesn't work on qcow2, unless we add
> fsync after metadata updates.

But how do we define the data integrity guarantees to the user of
cache=writeback+fsync? It seems to require a rather detailed knowledge
of Linux's use of T_FLUSH operations.

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

>> (Or maybe ext3 actually is stupid enough to flush the whole fs even for
>> that case
>
> Sigh.

I'm also worried about ext3 here.

Regards,

Anthony Liguori