qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extensio


From: Eric Blake
Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension
Date: Mon, 4 Apr 2016 14:22:43 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 04/04/2016 01:58 PM, Alex Bligh wrote:
> Eric,
> 
>> Nothing requires the two uses to report at the same granularity.  THe
>> NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descriptors
>> as it sees fit (so it could report holes at a 4k granularity, but
>> dirtiness only at a 64k granularity) - all that matters is that when all
>> the descriptors have been sent, they total up to the length of the
>> original client request.  So by itself, granularity does not require
>> another command.
> 
> Sure, but given you can't report dirtiness without also reporting
> allocation, if they are are at different blocksize I'd rather they
> were in different commands, because otherwise the code to report
> block size needs to work at two different granularities.

We already state the client has to make two queries.  The client is NOT
querying block size, but a map of contiguous bytes of the file with the
same properties.

As an example usage,

C: NBD_CMD_BLOCK_SIZE: length 128k, offset 0, flags 0
S: NBD_REPLY_TYPE_BLOCK_SIZE: length 32 (4 descriptors):
     length 16384, status 0
     length 16384, status NBD_STATE_HOLE|NBD_STATE_ZERO
     length 81920, status 0
     length 16384, status NBD_STATE_ZERO
C: NBD_CMD_BLOCK_SIZE: length 128k, offset 0, flags NBD_CMD_FLAG_DIRTY
S: NBD_REPLY_TYPE_BLOCK_SIZE: length 16 (2 descriptors):
     length 65536, status 0
     length 65536, status NBD_STATE_CLEAN

would be a perfectly valid sequence of replies.  It tells the client
nothing about the guest block size (that information would be the same
whether the guest uses 512-byte, 1024-byte, or 4096-byte sectors?).  In
fact, you can't even tell if it is possible to track dirty information
in a granularity smaller than 64k, only that the results of this command
did not have anything smaller than that.  The command intentionally
separates modes of operation (you can't query allocation and
NBD_CMD_FLAG_DIRTY at the same time), in case the server has different
block size code under the hood for the two types of queries.

> 
>> At this point, I was just trying to rebase the proposal as originally
>> made by Denis and Pavel; perhaps they will have more insight on how they
>> envisioned using the command, or on whether we should try harder to make
>> this more of a two-way protocol (where the client can tell the server
>> when to mark something as clean, or when to start tracking whether
>> something is dirty).
> 
> I'm not sure it needs to be a two way protocol (see my strawman) but
> I'd like to know it's at least possibly useful.

Tracking generation ids on every sector is one implementation, but it is
not currently used by qemu for qcow2 images.  So forcing the
implementation to be exposed by having NBD track dirty information by
generation id would require qemu to start tracking new information that
it does not currently have.  Qemu's current implementation of dirty
information is a bitmap with no generation id, so the idea is that the
NBD command for exposing dirty sectors should likewise be no more
specific than a listing of run-length-encoded alternations between "this
part of the file is clean" and "this part of the file is dirty".

Even for an implementation that DOES track generation id on every
sector, you still have the case that you need out-of-band communication
to make use of it.  So the client would first send an out-of-band
message "set generation 123 as my line in the sand", then use NBD to
query dirty sectors (which returns clean for all sectors with id < 123,
and dirty for all sectors >= 123).

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]