From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ain3Q-0005bQ-T5 for qemu-devel@nongnu.org; Wed, 23 Mar 2016 13:58:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ain3N-0007x3-Ka for qemu-devel@nongnu.org; Wed, 23 Mar 2016 13:58:48 -0400 Received: from barbershop.grep.be ([89.106.240.122]:40931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ain3N-0007wS-C2 for qemu-devel@nongnu.org; Wed, 23 Mar 2016 13:58:45 -0400 Date: Wed, 23 Mar 2016 18:58:34 +0100 From: Wouter Verhelst Message-ID: <20160323175834.GC2467@grep.be> References: <1458742562-30624-1-git-send-email-den@openvz.org> <1458742562-30624-3-git-send-email-den@openvz.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <1458742562-30624-3-git-send-email-den@openvz.org> Subject: Re: [Qemu-devel] [Nbd] [PATCH 2/2] NBD proto: add GET_LBA_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: nbd-general@lists.sourceforge.net, Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2016 at 05:16:02PM +0300, Denis V. Lunev wrote: > From: Pavel Borzenkov >=20 > With the availability of sparse storage formats, it is often needed to > query status of a particular LBA range and read only those blocks of > data that are actually present on the block device. >=20 > To provide such information, the patch adds GET_LBA_STATUS extension > with one new NBD_CMD_GET_LBA_STATUS command. >=20 > There exists a concept of data dirtiness, which is required during, for > example, incremental block device backup. To express this concept via > NBD protocol, this patch also adds additional mode of operation to > NBD_CMD_GET_LBA_STATUS command. >=20 > Since NBD protocol has no notion of block size, and to mimic SCSI "GET > LBA STATUS" command more closely, it has been chosen to return a list of > extents in the response of NBD_CMD_GET_LBA_STATUS command, instead of a > bitmap. >=20 > Signed-off-by: Pavel Borzenkov > Reviewed-by: Roman Kagan > Signed-off-by: Denis V. Lunev > CC: Wouter Verhelst > CC: Paolo Bonzini > CC: Kevin Wolf > CC: Stefan Hajnoczi > --- > doc/proto.md | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++ > 1 file changed, 82 insertions(+) >=20 > diff --git a/doc/proto.md b/doc/proto.md > index cda213c..fff515d 100644 > --- a/doc/proto.md > +++ b/doc/proto.md > @@ -243,6 +243,8 @@ immediately after the global flags field in oldstyle = negotiation: > `NBD_CMD_TRIM` commands > - bit 6, `NBD_FLAG_SEND_WRITE_ZEROES`; should be set to 1 if the server > supports `NBD_CMD_WRITE_ZEROES` commands > +- bit 7, `NBD_FLAG_SEND_GET_LBA_STATUS`; should be set to 1 if the server > + supports `NBD_CMD_GET_LBA_STATUS` commands > =20 > ##### Client flags > =20 > @@ -477,6 +479,10 @@ The following request types exist: > =20 > Defined by the experimental `WRITE_ZEROES` extension; see below. > =20 > +* `NBD_CMD_GET_LBA_STATUS` (7) > + > + Defined by the experimental `GET_LBA_STATUS` extension; see below. > + > * Other requests > =20 > Some third-party implementations may require additional protocol > @@ -638,6 +644,82 @@ The server SHOULD return `ENOSPC` if it receives a w= rite zeroes request > including one or more sectors beyond the size of the device. It SHOULD > return `EPERM` if it receives a write zeroes request on a read-only expo= rt. > =20 > +### `GET_LBA_STATUS` extension > + > +With the availability of sparse storage formats, it is often needed to q= uery > +status of a particular LBA range and read only those blocks of data that= are > +actually present on the block device. > + > +Some storage formats and operations over such formats express a concept = of > +data dirtiness. Whether the operation is block device mirroring, > +incremental block device backup or any other operation with a concept of > +data dirtiness, they all share a need to provide a list of LBA ranges > +that this particular operation treats as dirty. > + > +To provide such class of information, `GET_LBA_STATUS` extension adds new > +`NBD_CMD_GET_LBA_STATUS` command which returns a list of LBA ranges with > +their respective states. > + > +* `NBD_CMD_GET_LBA_STATUS` (7) > + > + An LBA range status query request. Length and offset define the range > + of interest. The server MUST reply with a reply header, followed > + immediately by the following data: As Eric noted, please expand LBA at least once. > + - 32 bits, length of parameter data that follow (unsigned) > + - zero or more LBA status descriptors, each having the following > + structure: > + > + * 64 bits, offset (unsigned) > + * 32 bits, length (unsigned) > + * 16 bits, status (unsigned) > + > + unless an error condition has occurred. > + > + If an error occurs, the server SHOULD set the appropriate error code > + in the error field. The server MUST then either close the > + connection, or send *length of parameter data* bytes of data > + (which MAY be invalid). > + > + The type of information required by the client is passed to server i= n the > + command flags field. If the server does not implement requested type= or > + have no means to express it, it MUST NOT return an error, but instea= d MUST > + return a single LBA status descriptor with *offset* and *length* equ= al to > + the *offset* and *length* from request, and *status* set to `0`. > + > + The following request types are currently defined for the command: > + > + 1. Block provisioning state > + > + Upon receiving an `NBD_CMD_GET_LBA_STATUS` command with command flags > + field set to `NBD_FLAG_GET_ALLOCATED` (0x0), the server MUST return I prefer to have a non-zero flag value. > + the provisioning state of the device. The following provisionnig sta= tes > + are defined for the command: > + > + - `NBD_STATE_ALLOCATED` (0x0), LBA extent is present on the block = device; > + - `NBD_STATE_ZEROED` (0x1), LBA extent is present on the block dev= ice > + and contains zeroes; Presumably this should be "contains only zeroes"? Also, this may end up being a fairly expensive call for the server to process. Is it really useful? > + - `NBD_STATE_DEALLOCATED` (0x2), LBA extent is not present on the > + block device. A client MUST NOT make any assumptions about the > + contents of the extent. > + > + 2. Block dirtiness state > + > + Upon receiving an `NBD_CMD_GET_LBA_STATUS` command with command flags > + field set to `NBD_FLAG_GET_DIRTY` (0x1), the server MUST return > + the dirtiness status of the device. The following dirtiness states > + are defined for the command: > + > + - `NBD_STATE_DIRTY` (0x0), LBA extent is dirty; > + - `NBD_STATE_CLEAN` (0x1), LBA extent is clean. > + > + Generic NBD client implementation without knowledge of a particular = NBD > + server operation MUST NOT make any assumption on the meaning of the > + NBD_STATE_DIRTY or NBD_STATE_CLEAN states. That makes it a useless call. A server can read /dev/random to decide whether to send STATE_DIRTY or STATE_CLEAN, and still be compliant with this spec. Either the spec should define what it means for a block to be in a dirty state, or it should not talk about it. --=20 < ron> I mean, the main *practical* problem with C++, is there's like a doz= en people in the world who think they really understand all of its rule= s, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12 --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJW8tlKAAoJEMKUD5Ub3wqdiacP/1juIJY1+h1fTB3fU2FzJuH1 ynFjRSNYBnPGTz6o+oGB9oxoXdRQCUZdfEsUN+/Dn8tZ3XXyYv6grrUykDGnFnaf PVlj9IKLTKPVQEQauMNw8tfuxF1Q+ebCfet7Zax2GWloswkUngocaVvV2SdLDTab GbHvaq/7GUTjMtT/dwPuTNcAMVCcmig9h9gAtsDiuSfVBY/KDZFcAVWiT9u6TTr6 5eZnPmXNgQRFtMIvhcLouLU7piMj6kwYwswkkttisOfa3cOtfKt58ldVEEiy7t+F fX2n/EoRx79Kigzpj9Pl+fzJAJDPzeYR+6XG+Ov9hM3805HddmTseVoACBsu3YYY Lw+UwBueBn7rfTg96Uj25/g9p5TpgsArdOdWfVZrkfrRMp+Sgn/evbSsF7f6WHlK a7GKI98bXiWHVqXpOipfu+5Qe5H+rsBf7JYjeZGTgpAx0EelsiiJT+SuSrec2J44 RHmzH2SGAeRjSdcqC74GyMBH5AQi0zK//yI9nRnZaBNEJK9lYtTzKVPdZLi7MEdF iEMrUcr/X5RmtwKFXxGwb3GGHYjgWGIPbLIhnkZCBQDvrIrYXtj+JDYU77nD3Fgt EkbRhcFw8HbDUkeZLaM4upP3Q9A90CyxRMW3QJny5aMads/h/5lgbg9S3ih6LbYC U8EpLaz9VCU7S/Z+QDCx =jQ5Y -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--