Avi Kivity wrote:
Anthony Liguori wrote:
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=none is partially broken as well, since O_DIRECT writes might
hit an un-battery-packed write cache. I think cache=writeback will
send the necessary flushes, if the disk and the underlying filesystem
support them.
Sure, but this likely doesn't upset people that much since O_DIRECT has
always had this behavior. Using non-battery backed disks with writeback
enabled introduces a larger set of possible data integrity issues. I
think this case is acceptable to ignore because it's a straight forward
policy.
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.
It don't think we realistically can.
Maybe two fds? One open in O_SYNC and one not. Is such a thing sane?
(Or maybe ext3 actually is stupid enough to flush the whole fs even
for
that case
Sigh.
I'm also worried about ext3 here.
I'm just waiting for btrfs.
Even ext4 is saner but we'll get lots of bug reports while ext3 remains
common.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html