Re: JFYI: ext4 bug triggerable by kvm

[Anthony Liguori <anthony@codemonkey.ws>]

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