Message ID | 20211117170230.1128262-3-eblake@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | NBD 6.2-rc fixes | expand |
17.11.2021 20:02, Eric Blake wrote: > Now that the block layer supports 64-bit operations, we no longer have > to self-fragment requests larger than 2G, reverting the workaround > added in 890cbccb08 (nbd: Fix large trim/zero requests). > > Signed-off-by: Eric Blake<eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
On Wed, Nov 17, 2021 at 09:04:34PM +0300, Vladimir Sementsov-Ogievskiy wrote: > 17.11.2021 20:02, Eric Blake wrote: > > Now that the block layer supports 64-bit operations, we no longer have > > to self-fragment requests larger than 2G, reverting the workaround > > added in 890cbccb08 (nbd: Fix large trim/zero requests). > > > > Signed-off-by: Eric Blake<eblake@redhat.com> > > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Any preferences on whether this should be in 6.2, or deferred to 7.0?
17.11.2021 23:49, Eric Blake wrote: > On Wed, Nov 17, 2021 at 09:04:34PM +0300, Vladimir Sementsov-Ogievskiy wrote: >> 17.11.2021 20:02, Eric Blake wrote: >>> Now that the block layer supports 64-bit operations, we no longer have >>> to self-fragment requests larger than 2G, reverting the workaround >>> added in 890cbccb08 (nbd: Fix large trim/zero requests). >>> >>> Signed-off-by: Eric Blake<eblake@redhat.com> >> >> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > > Any preferences on whether this should be in 6.2, or deferred to 7.0? > In my opinion it's good for 6.2, if we are not very strict on "only real bug fixes in hard freeze". The commit is obviously safe: if it break something, it means that feature we already included into 6.2 is broken anyway :)
diff --git a/nbd/server.c b/nbd/server.c index 85877f630533..1b3945220bd3 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -2509,16 +2509,8 @@ static coroutine_fn int nbd_handle_request(NBDClient *client, if (request->flags & NBD_CMD_FLAG_FAST_ZERO) { flags |= BDRV_REQ_NO_FALLBACK; } - ret = 0; - /* FIXME simplify this when blk_pwrite_zeroes switches to 64-bit */ - while (ret >= 0 && request->len) { - int align = client->check_align ?: 1; - int len = MIN(request->len, QEMU_ALIGN_DOWN(BDRV_REQUEST_MAX_BYTES, - align)); - ret = blk_pwrite_zeroes(exp->common.blk, request->from, len, flags); - request->len -= len; - request->from += len; - } + ret = blk_pwrite_zeroes(exp->common.blk, request->from, request->len, + flags); return nbd_send_generic_reply(client, request->handle, ret, "writing to file failed", errp); @@ -2532,16 +2524,7 @@ static coroutine_fn int nbd_handle_request(NBDClient *client, "flush failed", errp); case NBD_CMD_TRIM: - ret = 0; - /* FIXME simplify this when blk_co_pdiscard switches to 64-bit */ - while (ret >= 0 && request->len) { - int align = client->check_align ?: 1; - int len = MIN(request->len, QEMU_ALIGN_DOWN(BDRV_REQUEST_MAX_BYTES, - align)); - ret = blk_co_pdiscard(exp->common.blk, request->from, len); - request->len -= len; - request->from += len; - } + ret = blk_co_pdiscard(exp->common.blk, request->from, request->len); if (ret >= 0 && request->flags & NBD_CMD_FLAG_FUA) { ret = blk_co_flush(exp->common.blk); }
Now that the block layer supports 64-bit operations, we no longer have to self-fragment requests larger than 2G, reverting the workaround added in 890cbccb08 (nbd: Fix large trim/zero requests). Signed-off-by: Eric Blake <eblake@redhat.com> --- nbd/server.c | 23 +++-------------------- 1 file changed, 3 insertions(+), 20 deletions(-)