Re: JFYI: ext4 bug triggerable by kvm

[Michael Tokarev <mjt@tls.msk.ru>]

17.08.2010 18:28, Christoph Hellwig wrote:
> On Tue, Aug 17, 2010 at 09:20:37AM -0500, Anthony Liguori wrote:
[]
>> 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.
> 
> Define normal writes.  For cache=none and cache=writeback we don't
> have to, and instead do explicit calls to fsync()/fdatasync() calls
> when a we a cache flush from the guest.  For data=writethrough we
> guarantee data has made it to disk, and we implement this using
> O_DSYNC/O_SYNC when opening the file.  That tells the operating system
> to not return until data has hit the disk.   For Linux this is
> internally implement using a range-fsync/fdatasync after the actual
> write.

And this is actually what I mentioned in the very beginning,
in a hopefully-single-thread-email I've sent.  Mentioned
that ext4 is very slow when using with O_SYNC (without O_DIRECT).

I still had no opportunity to collect more info on this, and
yes, I've seen your (Christoph's) speed tests of a few FSes
in the famous "BTRFS: Unbelievably slow with kvm/qemu" thread.
A few users reported _insane_ write speeds of qcow2 files
with default cache mode on ext4.

And this is what prompted all this discussion (which actually
has nothing to do with the $subject line ;), -- an attempt
to think about replacing O_SYNC/fsync() with something
"lighter"...

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

We don't do sync on every write, but O_SYNC implies that.
And apparently it is what happening behind the scenes in
ext4 O_SYNC case.

But ok....

/mjt