From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqLyL-0006qX-Qk for qemu-devel@nongnu.org; Wed, 13 Apr 2016 10:40:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqLyK-0002e6-UG for qemu-devel@nongnu.org; Wed, 13 Apr 2016 10:40:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqLyK-0002du-M0 for qemu-devel@nongnu.org; Wed, 13 Apr 2016 10:40:48 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <20160405040527.GA4183@noname.redhat.com> <5703C0EC.6080306@redhat.com> <5706388D.50100@virtuozzo.com> <57068692.2080208@redhat.com> <20160413123854.GA3985@phobos> From: Eric Blake Message-ID: <570E5A6E.1040909@redhat.com> Date: Wed, 13 Apr 2016 08:40:46 -0600 MIME-Version: 1.0 In-Reply-To: <20160413123854.GA3985@phobos> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5DXawLUWBQbskhumgUPG4EH7TvNJoJ6GG" Subject: Re: [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Borzenkov Cc: Vladimir Sementsov-Ogievskiy , Paolo Bonzini , Kevin Wolf , nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Stefan Hajnoczi , Wouter Verhelst , "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5DXawLUWBQbskhumgUPG4EH7TvNJoJ6GG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/13/2016 06:38 AM, Pavel Borzenkov wrote: >> I'm also starting to think that it is worth FIRST documenting an >> extension for advertising block sizes, so that we can then couch >> BLOCK_STATUS in those terms (a server MUST NOT subdivide status into >> finer granularity than the advertised block sizes). >=20 > Why do you need to operate with blocks instead of list of extents? It's still a list of extents, just that having a definition of block sizes means that we can then require that the list of extents will not be subdivided smaller than a particular block size (so the client doesn't have to worry about a server overwhelming it with extents covering 1 byte each). > What benefits will this approach provide for a client or a server? >=20 > Are you still working on the spec? I can update the patch with > information about server-side limit/beyond request's length replies and= > post v3, so that things keep moving forward. You're welcome to post a v3, if you don't want to wait for me to get around to it. There's a lot going on in the spec right now, and I'm hoping to help flush some of the pending patches first. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --5DXawLUWBQbskhumgUPG4EH7TvNJoJ6GG 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/ iQEcBAEBCAAGBQJXDlpuAAoJEKeha0olJ0Nqxg8H/0qznv84F5tMI3zshYxgu/z0 uwUQvbFRyFs08x1wjXVQY3h8KcckcXipGph/zLt791AiPebOa830tH2PxIdnnYJt Xf2QiiowOJ62FM2oavy74/69wVWuedgfXQeCcyTbSykJUGutHRb6Rdeisu74oVC7 lOzjzm+K0kGj73GKcooh4FIIs4rV2zUyVZv8krYuXsTh65BtdhZx1xD+GlSf313l UChZV1vkTHpxCb4Za6QndKDNahkglji4/t0ofs68vfbOWfMzgsDo7Ubj5TF+/OGB Y1eiEojZ0UM1VDmxdtokjIUsYc2xhXD81BugCu84Rzc4rQGC28XSBhYdT1+pUl0= =6fG/ -----END PGP SIGNATURE----- --5DXawLUWBQbskhumgUPG4EH7TvNJoJ6GG--