qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "fam@euphon.net" <fam@euphon.net>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Denis Lunev <den@virtuozzo.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	"jsnow@redhat.com" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] block: blk_co_pcache
Date: Mon, 17 Jun 2019 15:20:53 +0200	[thread overview]
Message-ID: <20190617132053.GI7397@linux.fritz.box> (raw)
In-Reply-To: <cbec5fee-8c57-f929-28b0-e68e1992c757@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

Am 17.06.2019 um 15:09 hat Eric Blake geschrieben:
> On 6/17/19 7:09 AM, Kevin Wolf wrote:
> 
> >>>
> >>> Hmm, don't you think that blk_co_pcache sends NBD_CMD_CACHE if called on nbd driver?
> >>> I didn't implement it. But may be I should..
> >>>
> >>> May aim was only to avoid extra allocation and unnecessary reads. But if we implement
> >>> full-featured io request, what should it do?
> >>>
> >>> On qcow2 with backing it should pull data from backing to top, like in copy-on-read.
> >>> And for nbd it will send NBD_CMD_CACHE?
> >>> These semantics seems different, but why not?
> >>>
> >>
> >> Any opinions here? Should I resend or could we use it as a first step,
> >> not touching external API but improving things a little bit?
> > 
> > I'm not opposed to making only a first step now. The interface seems to
> > make sense to me; the only thing that I don't really like is the naming
> > both of the operation (blk_co_pcache) and of the flag (BDRV_REQ_CACHE)
> > because to me, "cache" doesn't mean "read, but ignore the result".
> > 
> > The operation only results in something being cached if the block graph
> > is configured to cache things. And indeed, the most importatn use case
> > for the flag is not populating a cache, but triggering copy-on-read. So
> > I think calling this operation "cache" is misleading.
> > 
> > Now, I don't have very good ideas for better names either. I guess
> > BDRV_REQ_NO_DATA could work, though it's not perfect. (Also, not sure if
> > a blk_co_preadv_no_read wrapper is even needed when you can just call
> > blk_co_preadv with the right flag.)
> > 
> > I'm open for good naming ideas.
> 
> Would 'prefetch' be a more useful name? The name NBD_CMD_CACHE was
> chosen in the NBD project, but we are not stuck to that name if we think
> something better makes more sense.

Whether 'prefetch' is entirely accurate really depends on the graph
configuration, too. But at least it gives me the right idea of "read
something, but don't return it yet", so yes, I think that would work for
me.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2019-06-17 13:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 13:48 [Qemu-devel] [PATCH 0/3] block: blk_co_pcache Vladimir Sementsov-Ogievskiy
2019-06-06 13:48 ` [Qemu-devel] [PATCH 1/3] block: implement blk_co_pcache Vladimir Sementsov-Ogievskiy
2019-06-06 13:48 ` [Qemu-devel] [PATCH 2/3] block/stream: use blk_co_pcache Vladimir Sementsov-Ogievskiy
2019-06-06 13:48 ` [Qemu-devel] [PATCH 3/3] nbd: improve CMD_CACHE: " Vladimir Sementsov-Ogievskiy
2019-06-06 13:55 ` [Qemu-devel] [PATCH 0/3] block: blk_co_pcache Eric Blake
2019-06-06 14:07   ` Vladimir Sementsov-Ogievskiy
2019-06-17 11:20     ` Vladimir Sementsov-Ogievskiy
2019-06-17 12:09       ` Kevin Wolf
2019-06-17 12:32         ` Vladimir Sementsov-Ogievskiy
2019-06-17 13:09         ` Eric Blake
2019-06-17 13:20           ` Kevin Wolf [this message]
2019-06-18  7:38             ` Vladimir Sementsov-Ogievskiy
2019-06-18  8:23               ` Kevin Wolf

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=20190617132053.GI7397@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=eblake@redhat.com \
    --cc=fam@euphon.net \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).