From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apUsG-0003ZN-Qe for qemu-devel@nongnu.org; Mon, 11 Apr 2016 01:59:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apUsF-0007Is-EX for qemu-devel@nongnu.org; Mon, 11 Apr 2016 01:59:00 -0400 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]:53343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apUsF-0007IM-8N for qemu-devel@nongnu.org; Mon, 11 Apr 2016 01:58:59 -0400 From: Markus Pargmann Date: Mon, 11 Apr 2016 07:58:33 +0200 Message-ID: <2168879.ApzZXSCWXO@galactica> In-Reply-To: <5703C298.9050505@redhat.com> References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <3980532.fxrjpRpJRt@adelgunde> <5703C298.9050505@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3102721.kHERzydJnN"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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: Paolo Bonzini Cc: nbd-general@lists.sourceforge.net, Eric Blake , Kevin Wolf , qemu-devel@nongnu.org, Pavel Borzenkov , Stefan Hajnoczi , "Denis V. Lunev" , Wouter Verhelst --nextPart3102721.kHERzydJnN Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Tuesday 05 April 2016 15:50:16 Paolo Bonzini wrote: >=20 > On 05/04/2016 11:24, Markus Pargmann wrote: > > Also it is uncertain if these status bits may change over time thro= ugh > > reorganization of backend storage, for example holes may be removed= in > > the backend and so on. Is it safe to cache this stuff? >=20 > If there's no concurrent access, it is. Even if it is out of date, i= t > is still a valid representation. For example, suppose a file has a > hole. The client knows that *its own client* (whoever's using /dev/n= bd0 > for example) should write to it before relying on the contents of the= > area. This remains true if a hole becomes a non-hole. >=20 > If there's concurrent access, all bets are off. Suppose a zero area > loses the zero flag. Client A knows that the area remains zero unles= s > someone has written to it. If *another* client B has concurrently > written something, there must be a communication mechanism by which B= > tells A to invalidate the cache, or A must not cache the > information---and probably should not request it in the first place. >=20 > > Until now something like READ and WRITE where somehow atomic operat= ions > > in the protocol. >=20 > No, they weren't. If you have overlapping I/O from multiple clients > there's no way to know what data you will get. You might even get ol= d > data and new data interspersed in a single read. There's definitely = no > guarantee of atomicity in either POSIX or NBD. At least from the protocol side they were atomic. You had one read/writ= e that does not rely on any other commands before or after. I think this was mostly a misunderstanding of the "SHOULD" sentence. I = was assuming that should would more be like a "must" which would have intro= duced strange requirements for the client, for example that it has to receive= the block status before making any reads. And this as well would have lead = to possibly complicated interaction between two clients receiving block st= atus before reading. But there was a mail recently which referenced rfc2119 so everything is= fine with that. Best Regards, Markus =2D-=20 Pengutronix e.K. | = | Industrial Linux Solutions | http://www.pengutronix.de/= | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 = | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-555= 5 | --nextPart3102721.kHERzydJnN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXCz0JAAoJECi9+rkzbKwyAxoP/ia4nc/oiMwAre6htNCzme13 8kcCs3/W0IAWOs2PwefZbAw/NKSl5EbOL8klTBhUbVctlQXkXfkxJTTxWrIC+lQZ KS5sAzFcVpYvWqeaOysbIM5i421/+Wmn3RA1Bo38+yjhZ3q/ZUfHatum+G/D9LOA gpbHpLHXxSDt0kNtoPJbSCoFjLfjmrKCNFiK4lJ4eUFMK0t8KzDSWqolm2ZKNYT8 76GQ5ije9wKXbouleqjYmFSQ2rFfPGEKTM7ca4UGjNf4QF9FHsB0TV6VfM+n7eNn 48lxCYjb2M2sfPuqVDgtoPQzNFLWxCD3lX60npUg173BEKgzz9Muv+TmTLX+0KaV Lkk+S1DQ4r+2/yj+5WO6KO8UB4JSF0IEp+qPKbYqVKIrAO6KYPf4zyCsU4yW+iB5 Z8httXHeqDrKn+5SfkTJ1SdJSPjxeZGAatQDoSEPIp3V8fbhsW3p08hL2QuTNBRU IvOyjiGbtcsszKMayZSjEN4p3bgZQIBGS1EkwrkSFQaKdyp3fvC9LZV63cc0bANm BATpZCLeas7XmvPFN7jvHNmLk4RallaXKPN6+lBe7WN7V5+W4DKAlZhLBCerMFtu Eb3HOk1kSfAPGP5X4k+daKt4lnvaZ5sKtVVX6d0nPGA+dofl0baH5gXV85Iz4cL/ exjk4VeF0msVPtNe8/Ul =L5qS -----END PGP SIGNATURE----- --nextPart3102721.kHERzydJnN--