From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] virtio-spec: document block CMD and FLUSH Date: Tue, 04 May 2010 11:34:38 +0300 Message-ID: <4BDFDC1E.5070500@redhat.com> References: <20100218222220.GA14847@redhat.com> <201005041408.25069.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , virtualization@lists.linux-foundation.org, Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org, hch@lst.de, Neil Brown , Jens Axboe , tytso@mit.edu To: Rusty Russell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59598 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755801Ab0EDIfH (ORCPT ); Tue, 4 May 2010 04:35:07 -0400 In-Reply-To: <201005041408.25069.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: 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