From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER Date: Wed, 19 Dec 2012 13:46:53 -0500 Message-ID: <20121219184653.GD15037@phenom.dumpdata.com> References: <1334595957-12552-1-git-send-email-stefano.stabellini@eu.citrix.com> <20120425084524.GA17537@lst.de> <1335344565.28015.7.camel@zakaz.uk.xensource.com> <20120425102024.GA19800@lst.de> <20120425112335.GA20868@lst.de> <20120426154101.GD26830@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Stefano Stabellini Cc: "kwolf@redhat.com" , "xen-devel@lists.xensource.com" , Christoph Hellwig , Ian Campbell , "qemu-devel@nongnu.org" List-Id: xen-devel@lists.xenproject.org On Wed, May 09, 2012 at 01:42:41PM +0100, Stefano Stabellini wrote: > On Thu, 26 Apr 2012, Konrad Rzeszutek Wilk wrote: > > On Wed, Apr 25, 2012 at 01:23:35PM +0200, Christoph Hellwig wrote: > > > On Wed, Apr 25, 2012 at 12:21:53PM +0100, Stefano Stabellini wrote: > > > > That is true, in fact I couldn't figure out what I had to implement just > > > > reading the comment. So I went through the blkback code and tried to > > > > understand what I had to do, but I got it wrong. > > > > > > > > Reading the code again it seems to me that BLKIF_OP_FLUSH_DISKCACHE > > > > is supposed to have the same semantics as REQ_FLUSH, that implies a > > > > preflush if nr_segments > 0, not a postflush like I did. > > > > > > It's worse - blkfront translates both a REQ_FLUSH or a REQ_FUA > > > into BLKIF_OP_FLUSH_DISKCACHE. > > > > I think that is what remained of the BARRIER request. > > > > > > REQ_FLUSH either is a pre flush or a pure flush without a data transfer, > > > and REQ_FUA is a post flush. So to get the proper semantics you'll have > > > to do both, _and_ sequence it so that no operation starts before the > > > previous one finished. > > > > If I were to emulate the SCSI SYNC command which one would it be? > > > > I think REQ_FLUSH? In which I would think that the blkfront needs to > > get rid of the REQ_FUA part? > > > > ping? And just shy of 7 months later I answer :-) I think you are right. Getting rid of REQ_FUA looks like the right way. Oh, and blkfront already does that! 1290 err = xenbus_gather(XBT_NIL, info->xbdev->otherend, 1291 "feature-flush-cache", "%d", &flush, 1292 NULL); 1293 1294 if (!err && flush) { 1295 info->feature_flush = REQ_FLUSH; 1296 info->flush_op = BLKIF_OP_FLUSH_DISKCACHE; 1297 } 1298 So what I am missing? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel