Re: [PATCH] virtio-blk: fallback to draining the queue if barrier ops are not supported

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 14, 2009 at 07:38:45PM +0400, Michael Tokarev wrote:
> Avi Kivity wrote:
> >Early implementations of virtio devices did not support barrier operations,
> >but did commit the data to disk.  In such cases, drain the queue to emulate
> >barrier operations.
> 
> Are there any implementation currently that actually supports barriers?
> As far as I remember there's no way to invoke barriers from a user-space
> application on linux, and this is how kvm/qemu is running on this OS.

Ignore all the barrier talk.  The way Linux uses the various storage
transport the primitives are queue draining (done entirely in the guest
block layer) and cache flushes.  Fdatasync is exactly the same primitive
as a WIN FLUSH CACHE in ATA or SYNCHRONIZE cache in SCSI module the lack
or ranges in fdatasync - but that is just a performance optimization and
not actually used by Linux guests for now.

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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux