From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Christoph Hellwig <hch@lst.de>,
Ian Campbell <Ian.Campbell@citrix.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER
Date: Wed, 19 Dec 2012 13:46:53 -0500 [thread overview]
Message-ID: <20121219184653.GD15037@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205091342290.26786@kaball-desktop>
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
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Christoph Hellwig <hch@lst.de>,
Ian Campbell <Ian.Campbell@citrix.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
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 [thread overview]
Message-ID: <20121219184653.GD15037@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205091342290.26786@kaball-desktop>
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
next prev parent reply other threads:[~2012-12-19 18:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 17:05 [PATCH] xen_disk: implement BLKIF_OP_FLUSH_DISKCACHE, remove BLKIF_OP_WRITE_BARRIER Stefano Stabellini
2012-04-16 17:10 ` Konrad Rzeszutek Wilk
2012-04-25 8:45 ` Christoph Hellwig
2012-04-25 9:02 ` [Xen-devel] " Ian Campbell
2012-04-25 10:20 ` Christoph Hellwig
2012-04-25 11:21 ` Stefano Stabellini
2012-04-25 11:17 ` Ian Campbell
2012-04-25 11:23 ` Christoph Hellwig
2012-04-26 15:41 ` Konrad Rzeszutek Wilk
2012-05-09 12:42 ` [Qemu-devel] " Stefano Stabellini
2012-05-09 12:42 ` Stefano Stabellini
2012-12-19 18:46 ` Konrad Rzeszutek Wilk [this message]
2012-12-19 18:46 ` Konrad Rzeszutek Wilk
2013-01-09 18:44 ` [Qemu-devel] " Stefano Stabellini
2013-01-09 18:44 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121219184653.GD15037@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=hch@lst.de \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.