From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anB1N-0000MO-G6 for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:22:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anB1J-0000qu-GM for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:22:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anB1J-0000qq-8M for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:22:45 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <7AD0DCB1-1868-4AAD-A03D-C976A728DD75@alex.org.uk> <5702C1AB.8020601@redhat.com> From: Eric Blake Message-ID: <5702CD13.8080803@redhat.com> Date: Mon, 4 Apr 2016 14:22:43 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dC8IssP7CVVeKebTCvX88IVaqneicr5e1" Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , Kevin Wolf , "qemu-devel@nongnu.org" , Pavel Borzenkov , "Stefan stefanha@redhat. com" , "Denis V. Lunev" , Wouter Verhelst , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dC8IssP7CVVeKebTCvX88IVaqneicr5e1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/04/2016 01:58 PM, Alex Bligh wrote: > Eric, >=20 >> Nothing requires the two uses to report at the same granularity. THe >> NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descripto= rs >> 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 a= ll >> 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. >=20 > 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. >=20 >> 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 th= ey >> envisioned using the command, or on whether we should try harder to ma= ke >> 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). >=20 > 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 >=3D 123). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --dC8IssP7CVVeKebTCvX88IVaqneicr5e1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXAs0TAAoJEKeha0olJ0NqessIAKPVIadYlheZacT182jwDuAc bWYjQ3/YAe8sojJ593OqEDQKK0hJtuOt5NPMszh/+uMV37kqNsgcLocWKndvKnEq OyfBw8rMDkUconqBJWtTPkPcnGEITLE6Iu08hXWVHrFnxHMPQeiGLjcw69Jasj32 RfQbx61ksxixZfNfPBm+B0oqhH7jW3MHWFklSp0yybCHwqBMY0zVdQQ8Rkx2Xot5 MZ0PhHZP7oID/l/gsK0Uk6d7VMWzHTnXcJsy7KtS8TPlzP+SMWLSTh7wrcpQtqlu lsjZkwajLAApQtyJ6FyVAr2ZG3gOMCiH9jPRRgdYw5Wp+8L1s8WVqLJDxs2pPuQ= =a5l1 -----END PGP SIGNATURE----- --dC8IssP7CVVeKebTCvX88IVaqneicr5e1--