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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
