From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anRNF-0007w9-8S for qemu-devel@nongnu.org; Tue, 05 Apr 2016 09:50:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anRNC-00069L-2J for qemu-devel@nongnu.org; Tue, 05 Apr 2016 09:50:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anRNB-000699-RI for qemu-devel@nongnu.org; Tue, 05 Apr 2016 09:50:25 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <3980532.fxrjpRpJRt@adelgunde> From: Paolo Bonzini Message-ID: <5703C298.9050505@redhat.com> Date: Tue, 5 Apr 2016 15:50:16 +0200 MIME-Version: 1.0 In-Reply-To: <3980532.fxrjpRpJRt@adelgunde> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pQXCn6Q7wMbmGPe39b4E1CSh36qx5nCVe" 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 , Wouter Verhelst , "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pQXCn6Q7wMbmGPe39b4E1CSh36qx5nCVe Content-Type: multipart/mixed; boundary="hGM7nnegrPmUPuexdFOeaBtUtEGHPHpEn" From: Paolo Bonzini To: Markus Pargmann , nbd-general@lists.sourceforge.net Cc: Eric Blake , Kevin Wolf , qemu-devel@nongnu.org, Pavel Borzenkov , Stefan Hajnoczi , "Denis V. Lunev" , Wouter Verhelst Message-ID: <5703C298.9050505@redhat.com> Subject: Re: [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <3980532.fxrjpRpJRt@adelgunde> In-Reply-To: <3980532.fxrjpRpJRt@adelgunde> --hGM7nnegrPmUPuexdFOeaBtUtEGHPHpEn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05/04/2016 11:24, Markus Pargmann wrote: > 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 there's no concurrent access, it is. Even if it is out of date, it is still a valid representation. For example, suppose a file has a hole. The client knows that *its own client* (whoever's using /dev/nbd0 for example) should write to it before relying on the contents of the area. This remains true if a hole becomes a non-hole. 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 unless 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. > Until now something like READ and WRITE where somehow atomic operations= > in the protocol. 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 old data and new data interspersed in a single read. There's definitely no guarantee of atomicity in either POSIX or NBD. Thanks, Paolo --hGM7nnegrPmUPuexdFOeaBtUtEGHPHpEn-- --pQXCn6Q7wMbmGPe39b4E1CSh36qx5nCVe 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 iQEcBAEBCAAGBQJXA8KYAAoJEL/70l94x66DX+EH+wY0nDu33L/IdLHKaqKHHBNS JRiD6mnR5IFE2tFuSc0btTV0/bRoeScvbNRetSWIxSpCKhpfprNv6kSaVW3hD1f4 1tJ9ax5/Se6ucnJjQCFfRpezX39atl23cXGNrfrv2HgsY7TlewOAgYlsa0dbwfKt xQdHKwtJ6s5fL3nRF9xD7xL1XlwThOvI5+n17W4IoEwCcoub+0f6ZhVFHOsSBkGx Y+tkOQVDH28z49n2huE9zZYiztb8nRb47d5N3Xe+0k3QkFfOrwaGk3cFNIwEUvsi jxrVATVQGCE9w2Pv0SDuI2Xo8kzRDtfKI2V9Tm/LYipv4637L8iSYmaJHSkx74I= =UhBu -----END PGP SIGNATURE----- --pQXCn6Q7wMbmGPe39b4E1CSh36qx5nCVe--