On Wed, Oct 14, 2009 at 08:03:41PM +0900, Avi Kivity wrote: > >Can't remember anything like that. The "bug" was the complete lack of > >cache flush infrastructure for virtio, and the lack of advertising a > >volative write cache on ide. > > > > By "complete flush infrastructure", you mean host-side and guest-side > support for a new barrier command, yes?
The cache flush command, not barrier command. The new virtio code implements barrier the same way we do for IDE and SCSI - all barrier semantics are implemented by generic code in the block layer by draining the queues, the only thing we send over the wire are cache flush commands in strategic places. > But can't this be also implemented using QUEUE_ORDERED_DRAIN, and on the > host side disabling the backing device write cache? I'm talking about > cache=none, primarily. Yes, it could. But as I found out in a long discussion with Stephen it's not actually nessecary. All filesystems do the right thing for a device not claiming to support barriers if it doesn't include write caches, that is implement ordering internally. So there is no urge to set QUEUE_ORDERED_DRAIN for the case without write cache. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
