From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH] virtio-blk: fallback to draining the queue if barrier ops are not supported Date: Wed, 14 Oct 2009 17:46:17 +0200 Message-ID: <20091014154617.GA19549@lst.de> References: <4AD5B00D.102@redhat.com> <1255521788-24346-1-git-send-email-avi@redhat.com> <4AD5F085.8040909@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Christoph Hellwig , Matthew Tippett , Dustin Kirkland , Anthony Liguori , RW , kvm@vger.kernel.org To: Michael Tokarev Return-path: Received: from verein.lst.de ([213.95.11.210]:41549 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934588AbZJNPrI (ORCPT ); Wed, 14 Oct 2009 11:47:08 -0400 Content-Disposition: inline In-Reply-To: <4AD5F085.8040909@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: 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.