Re: JFYI: ext4 bug triggerable by kvm

Anthony Liguori
2010-08-17T14:20:43Z

On 08/17/2010 08:07 AM, Christoph Hellwig wrote:
>> The point is that we don't want to flush the disk write cache. The
>> intention of writethrough is not to make the disk cache writethrough
>> but to treat the host's cache as writethrough.
>>
>
> We need to make sure data is not in the disk write cache if want to
> provide data integrity.

When the guest explicitly flushes the emulated disk's write cache. Not
on every single write completion.

> It has nothing to do with the qemu caching
> mode - for data=writeback or none it's commited as part of the fdatasync
> call, and for data=writethrough it's commited as part of the O_SYNC
> write. Note that both these path end up calling the filesystems ->fsync
> method which is what's require to make writes stable. That's exactly
> what is missing out in sync_file_range, and that's why that API is not
> useful at all for data integrity operations.

For normal writes from a guest, we don't need to follow the write with
an fsync(). We should only need to issue an fsync() given an explicit
flush from the guest.

> It's also what makes
> fsync slow on extN - but the fix to that is not to not provide data
> integrity but rather to make fsync fast. There's various other
> filesystems that can already do it, and if you insist on using those
> that are slow for this operation you'll have to suffer until that
> issue is fixed for them.
>

fsync() being slow is orthogonal to my point. I don't see why we need
to do an fsync() on *every* write. It should only be necessary when a
guest injects an actual barrier.

Regards,

Anthony Liguori