From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9Dal-0006aH-Nw for qemu-devel@nongnu.org; Tue, 04 May 2010 04:34:59 -0400 Received: from [140.186.70.92] (port=46775 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9Dak-0006Zu-9v for qemu-devel@nongnu.org; Tue, 04 May 2010 04:34:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9Dai-0007Xq-E0 for qemu-devel@nongnu.org; Tue, 04 May 2010 04:34:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20620) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9Dai-0007X9-50 for qemu-devel@nongnu.org; Tue, 04 May 2010 04:34:56 -0400 Message-ID: <4BDFDC1E.5070500@redhat.com> Date: Tue, 04 May 2010 11:34:38 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20100218222220.GA14847@redhat.com> <201005041408.25069.rusty@rustcorp.com.au> In-Reply-To: <201005041408.25069.rusty@rustcorp.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] virtio-spec: document block CMD and FLUSH List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: tytso@mit.edu, kvm@vger.kernel.org, "Michael S. Tsirkin" , Neil Brown , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Jens Axboe , hch@lst.de On 05/04/2010 07:38 AM, Rusty Russell wrote: > On Fri, 19 Feb 2010 08:52:20 am Michael S. Tsirkin wrote: > >> I took a stub at documenting CMD and FLUSH request types in virtio >> block. Christoph, could you look over this please? >> >> I note that the interface seems full of warts to me, >> this might be a first step to cleaning them. >> > ISTR Christoph had withdrawn some patches in this area, and was waiting > for him to resubmit? > > I've given up on figuring out the block device. What seem to me to be sane > semantics along the lines of memory barriers are foreign to disk people: they > want (and depend on) flushing everywhere. > > For example, tdb transactions do not require a flush, they only require what > I would call a barrier: that prior data be written out before any future data. > Surely that would be more efficient in general than a flush! In fact, TDB > wants only writes to *that file* (and metadata) written out first; it has no > ordering issues with other I/O on the same device. > I think that's SCSI ordered tags. > A generic I/O interface would allow you to specify "this request depends on these > outstanding requests" and leave it at that. It might have some sync flush > command for dumb applications and OSes. The userspace API might be not be as > precise and only allow such a barrier against all prior writes on this fd. > Depends on all previous requests, and will commit before all following requests. ie a full barrier. > ISTR someone mentioning a desire for such an API years ago, so CC'ing the > usual I/O suspects... > I'd love to see TCQ exposed to user space. -- error compiling committee.c: too many arguments to function