| Message ID | 1479413642-22463-2-git-send-email-eblake@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 17.11.2016 21:13, Eric Blake wrote: > Commit fa778fff wired up support to send the NBD_CMD_WRITE_ZEROES, > but forgot to inform the block layer that FUA unmapping of zeroes is > supported. Without BDRV_REQ_MAY_UNMAP listed as a supported flag, > the block layer will always insist on the NBD layer passing > NBD_CMD_FLAG_NO_HOLE, resulting in the server always allocating > things even when it was desired to let the server punch holes. > Similarly, failing to set BDRV_REQ_FUA means that the client may > send unnecessary NBD_CMD_FLUSH when it could have instead used the > NBD_CMD_FLAG_FUA bit. > > CC: qemu-stable@nongnu.org > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > block/nbd-client.c | 4 ++++ > 1 file changed, 4 insertions(+) Reviewed-by: Max Reitz <mreitz@redhat.com>
On 11/17/2016 03:10 PM, Max Reitz wrote: > On 17.11.2016 21:13, Eric Blake wrote: >> Commit fa778fff wired up support to send the NBD_CMD_WRITE_ZEROES, >> but forgot to inform the block layer that FUA unmapping of zeroes is >> supported. Without BDRV_REQ_MAY_UNMAP listed as a supported flag, >> the block layer will always insist on the NBD layer passing >> NBD_CMD_FLAG_NO_HOLE, resulting in the server always allocating >> things even when it was desired to let the server punch holes. >> Similarly, failing to set BDRV_REQ_FUA means that the client may >> send unnecessary NBD_CMD_FLUSH when it could have instead used the >> NBD_CMD_FLAG_FUA bit. >> >> CC: qemu-stable@nongnu.org I guess this one is technically not for qemu-stable (as fa778fff is not part of 2.7); rather, I just got carried away with the CC lines distinguishing the first half of my series for 2.8 vs. the second for 2.9. >> Signed-off-by: Eric Blake <eblake@redhat.com> >> --- >> block/nbd-client.c | 4 ++++ >> 1 file changed, 4 insertions(+) > > Reviewed-by: Max Reitz <mreitz@redhat.com> >
On 17/11/2016 22:10, Max Reitz wrote: > On 17.11.2016 21:13, Eric Blake wrote: >> Commit fa778fff wired up support to send the NBD_CMD_WRITE_ZEROES, >> but forgot to inform the block layer that FUA unmapping of zeroes is >> supported. Without BDRV_REQ_MAY_UNMAP listed as a supported flag, >> the block layer will always insist on the NBD layer passing >> NBD_CMD_FLAG_NO_HOLE, resulting in the server always allocating >> things even when it was desired to let the server punch holes. >> Similarly, failing to set BDRV_REQ_FUA means that the client may >> send unnecessary NBD_CMD_FLUSH when it could have instead used the >> NBD_CMD_FLAG_FUA bit. >> >> CC: qemu-stable@nongnu.org >> Signed-off-by: Eric Blake <eblake@redhat.com> >> --- >> block/nbd-client.c | 4 ++++ >> 1 file changed, 4 insertions(+) > > Reviewed-by: Max Reitz <mreitz@redhat.com> I'll take this one. Paolo
diff --git a/block/nbd-client.c b/block/nbd-client.c index 2a302de..3779c6c 100644 --- a/block/nbd-client.c +++ b/block/nbd-client.c @@ -415,6 +415,10 @@ int nbd_client_init(BlockDriverState *bs, } if (client->nbdflags & NBD_FLAG_SEND_FUA) { bs->supported_write_flags = BDRV_REQ_FUA; + bs->supported_zero_flags |= BDRV_REQ_FUA; + } + if (client->nbdflags & NBD_FLAG_SEND_WRITE_ZEROES) { + bs->supported_zero_flags |= BDRV_REQ_MAY_UNMAP; } qemu_co_mutex_init(&client->send_mutex);
Commit fa778fff wired up support to send the NBD_CMD_WRITE_ZEROES, but forgot to inform the block layer that FUA unmapping of zeroes is supported. Without BDRV_REQ_MAY_UNMAP listed as a supported flag, the block layer will always insist on the NBD layer passing NBD_CMD_FLAG_NO_HOLE, resulting in the server always allocating things even when it was desired to let the server punch holes. Similarly, failing to set BDRV_REQ_FUA means that the client may send unnecessary NBD_CMD_FLUSH when it could have instead used the NBD_CMD_FLAG_FUA bit. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> --- block/nbd-client.c | 4 ++++ 1 file changed, 4 insertions(+)