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