Re: JFYI: ext4 bug triggerable by kvm

Christoph Hellwig
2010-08-17T13:07:03Z

On Tue, Aug 17, 2010 at 07:56:04AM -0500, Anthony Liguori wrote:
> But assuming that you had a preallocated disk image, it would
> effectively flush the page cache so it sounds like the only real
> issue is sparse and growable files.

For preallocated as in using fallocate() we still converting unwritten
to regular extents and do have metadata updates. For preallocated as
in writining zeroes into the whole image earlier we do indeed only
care about the data, and will not have metadata for most filesystems.
That still leaves COW based filesystems that need to allocate new blocks
on every write, and from my reading NFS also needs the ->fsync callout
to actually commit unstable data to disk.

> > and even more importantly the disk write cache is
> >never flushed.
>
> 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. 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. 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.