From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anRkB-00022L-PT for qemu-devel@nongnu.org; Tue, 05 Apr 2016 10:14:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anRk6-0006wp-Rh for qemu-devel@nongnu.org; Tue, 05 Apr 2016 10:14:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anRk6-0006wX-K5 for qemu-devel@nongnu.org; Tue, 05 Apr 2016 10:14:06 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <3980532.fxrjpRpJRt@adelgunde> From: Eric Blake Message-ID: <5703C829.8070306@redhat.com> Date: Tue, 5 Apr 2016 08:14:01 -0600 MIME-Version: 1.0 In-Reply-To: <3980532.fxrjpRpJRt@adelgunde> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T9F9wGmj7fj6lPh4Fuaftwwh3rP1BqTvm" 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: Markus Pargmann , nbd-general@lists.sourceforge.net Cc: Kevin Wolf , qemu-devel@nongnu.org, Pavel Borzenkov , Stefan Hajnoczi , "Denis V. Lunev" , Wouter Verhelst , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T9F9wGmj7fj6lPh4Fuaftwwh3rP1BqTvm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/05/2016 03:24 AM, Markus Pargmann wrote: >> + requested. >> + >> + The client SHOULD NOT read from an area that has both >> + `NBD_STATE_HOLE` set and `NBD_STATE_ZERO` clear. >=20 > Why not? If we don't execute CMD_BLOCK_STATUS we wouldn't know about th= e > situation and would simply read directly. To fulfill this statement we > would need to receive the block status before every read operation. Because we already state that for NBD_CMD_TRIM, the client SHOULD NOT read an area where a trim was requested without an intervening write, precisely because the server MAY (but not MUST) cause the trim to create bogus reads for that area until another write happens. I was just trying to explain that the representation of HOLE and not ZERO represents the state created by a successful NBD_CMD_TRIM that the server honors, without being able to guarantee zero reads. >=20 > Also something that is kind of missing from the document so far is > concurrency with other NBD clients. Certainly most users do not use NBD= > for concurrent access to the backend storage. But for example the > sentence above ignores the fact that another client may work on the > backend and that the state may change after some time so that it may > still be necessary to read from an area with NBD_STATE_HOLE and > NBD_STATE_ZERO set. That's missing from NBD in general, and I don't think this is the patch to add it. We already have concurrency with self issues, because NBD server can handle requests out of order (within the bounds of FLUSH and FUA modifiers). >=20 > Also it is uncertain if these status bits may change over time through > reorganization of backend storage, for example holes may be removed in > the backend and so on. Is it safe to cache this stuff? If the client is the only thing modifying the drive, maybe we want to make that additional constraint on the server. But how best to word it, or is it too tight of a specification? >=20 > Until now something like READ and WRITE where somehow atomic operations= > in the protocol. Not really. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --T9F9wGmj7fj6lPh4Fuaftwwh3rP1BqTvm 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/ iQEcBAEBCAAGBQJXA8gpAAoJEKeha0olJ0Nq7i8IAKQCNtWs7+DznzZ76wGuIoFI 5kcAT9UIixJkyT+Y0Bi8NMBcLXIKRguXsZ59Cws0p610vuW0XIniZjrLw24VFXLP EhWncIbopO22d7VMxXizNim8rcpV4F3OTJhXjyPlvVvUCaRBpmbrw7lr9iu/44FD 0/jSxYm7xrTUmtgMC47Z48umwOqmmx8CeyVayl9YVX36gDrQd0k8icCz/5zD09WT QjEpDaNe7nERa4h5xUytYh+SU5wU6xBrilPtZmpPbx8jS5mczBayBaUDHEHcWHiq bV/4PQ9Tn8KPtEY+ppAHLobms8qs2lG+6n1T6wJSEg6mrMgbqH4Bb56WJgrqUGk= =iMcb -----END PGP SIGNATURE----- --T9F9wGmj7fj6lPh4Fuaftwwh3rP1BqTvm--