Re: [Qemu-devel] [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

Re: [Qemu-devel] [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

[Stefano Stabellini]

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?

Re: [Qemu-devel] [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

[Konrad Rzeszutek Wilk]

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

Re: [Qemu-devel] [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER

[Stefano Stabellini]

On Wed, 19 Dec 2012, Konrad Rzeszutek Wilk wrote:
> 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?

Nothing, thanks. I have updated and resent the patch, fixing the
implementation of BLKIF_OP_FLUSH_DISKCACHE.