Re: [Qemu-devel] [PATCH v5 14/14] nbd: Implement NBD_CMD_WRITE_ZEROES on client

[Eric Blake <eblake@redhat.com>]

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

On 07/19/2016 12:24 AM, Fam Zheng wrote:
> On Mon, 07/18 22:08, Eric Blake wrote:
>> Upstream NBD protocol recently added the ability to efficiently
>> write zeroes without having to send the zeroes over the wire,
>> along with a flag to control whether the client wants a hole.
>>

>> +int nbd_client_co_pwrite_zeroes(BlockDriverState *bs, int64_t offset,
>> +                                int count, BdrvRequestFlags flags)
>> +{
>> +    ssize_t ret;
>> +    NbdClientSession *client = nbd_get_client_session(bs);
>> +    struct nbd_request request = {
>> +        .type = NBD_CMD_WRITE_ZEROES,
>> +        .from = offset,
>> +        .len = count,
>> +    };
>> +    struct nbd_reply reply;
>> +
>> +    if (!(client->nbdflags & NBD_FLAG_SEND_WRITE_ZEROES)) {
>> +        return -ENOTSUP;
>> +    }
>> +
>> +    if (flags & BDRV_REQ_FUA) {
>> +        assert(client->nbdflags & NBD_FLAG_SEND_FUA);
>> +        request.flags |= NBD_CMD_FLAG_FUA;
>> +    }
>> +    if (!(flags & BDRV_REQ_MAY_UNMAP)) {
> 
> Correct me if I'm wrong, I don't think we care about BDRV_REQ_MAY_UNMAP here,
> the NBD protocol can never issue an unmap request. In other words I think
> NO_HOLE and MAY_UNMAP are two different things.

No. The server is (and should be) allowed to manage storage as
efficiently as it wants, and should only be required to fully allocate
storage if the client has requested that.  The NBD protocol CAN issue an
unmap request (NBD_CMD_TRIM), but we also document in the NBD protocol
that the server SHOULD be able to unmap instead of writing zeroes so
long as the result still reads as zeroes.  So we WANT to issue MAY_UNMAP
as an optimization in all cases except where the client specifically
asked for full allocation.  NO_HOLE and MAY_UNMAP are (supposed to be)
the same thing, except for being negated in sense based on what the
default value of 0 represents.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]