From: Eric Blake <eblake@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
hreitz@redhat.com, vsementsov@virtuozzo.com,
qemu-block@nongnu.org
Subject: [PATCH] nbd/client: Request larger block status by default
Date: Tue, 21 Sep 2021 11:17:03 -0500 [thread overview]
Message-ID: <20210921161703.2682802-1-eblake@redhat.com> (raw)
Now that commit 5a1cfd21 has clarified that a driver's block_status
can report larger *pnum than in the original request, we can take
advantage of that in the NBD driver. Rather that limiting our request
to the server based on the maximum @bytes our caller mentioned, we
instead ask for as much status as possible (the minimum of our 4G
limit or the rest of the export); the server will still only give us
one extent in its answer (because we are using NBD_CMD_FLAG_REQ_ONE),
but now the block layer's caching of data areas can take advantage of
cases where the server gives us a large answer to avoid the need for
future NBD_CMD_BLOCK_STATUS calls.
Signed-off-by: Eric Blake <eblake@redhat.com>
---
block/nbd.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/block/nbd.c b/block/nbd.c
index f6ff1c4fb472..7c4ec058b0aa 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1479,10 +1479,15 @@ static int coroutine_fn nbd_client_co_block_status(
BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
Error *local_err = NULL;
+ /*
+ * No need to limit our over-the-wire request to @bytes; rather,
+ * ask the server for as much as it can send in one go, and the
+ * block layer will then cap things.
+ */
NBDRequest request = {
.type = NBD_CMD_BLOCK_STATUS,
.from = offset,
.len = MIN(QEMU_ALIGN_DOWN(INT_MAX, bs->bl.request_alignment),
- MIN(bytes, s->info.size - offset)),
+ s->info.size - offset),
.flags = NBD_CMD_FLAG_REQ_ONE,
};
--
2.31.1
next reply other threads:[~2021-09-21 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 16:17 Eric Blake [this message]
2021-09-21 17:25 ` [PATCH] nbd/client: Request larger block status by default Vladimir Sementsov-Ogievskiy
2021-09-21 18:08 ` Eric Blake
2021-09-21 19:12 ` Vladimir Sementsov-Ogievskiy
2021-09-21 20:00 ` Eric Blake
2021-09-22 7:28 ` Vladimir Sementsov-Ogievskiy
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=20210921161703.2682802-1-eblake@redhat.com \
--to=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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).