On 06/27/2016 06:13 AM, Paolo Bonzini wrote: > > > On 26/06/2016 00:15, Eric Blake wrote: >> diff --git a/block/nbd.c b/block/nbd.c >> index 8d57220..049d1bd 100644 >> --- a/block/nbd.c >> +++ b/block/nbd.c >> @@ -357,6 +357,7 @@ static int nbd_co_flush(BlockDriverState *bs) >> static void nbd_refresh_limits(BlockDriverState *bs, Error **errp) >> { >> bs->bl.max_pdiscard = NBD_MAX_BUFFER_SIZE; >> + bs->bl.max_pwrite_zeroes = NBD_MAX_BUFFER_SIZE; > > I have probably asked before---is there any reason for these to be > limited, since the commands have no payload? Here's the last time it was brought up on the nbd-general list [1]. We have the potential BLOCK_SIZE handshake negotiation extension, where I was proposing that the server can advertise its actual limits (rather than the client having to guess them or rely on out-of-band information) - and I was proposing that NBD_CMD_TRIM and NBD_CMD_WRITE_ZEROES should be permitted to advertise additional limits that are larger than the NBD_CMD_WRITE limit, precisely because they don't carry a payload and can therefore be more efficient if done in bulk. [1] https://sourceforge.net/p/nbd/mailman/message/35081223/ But at the time of that thread, there was concern expressed whether adding and additional NBD_INFO for each NBD_CMD limit would scale well, or whether we need a different approach, and I haven't revisited the thread since that comment. At any rate, I have BLOCK_SIZE patches ready for qemu, once the WRITE_ZERO patches land, and where it should be easy to make this limit runtime-settable to a larger value from actual server limits, if we can decide how BLOCK_SIZE should advertise such a limit. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature