From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBJyS-0002bg-Dh for qemu-devel@nongnu.org; Mon, 28 Nov 2016 06:19:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBJyP-0001oe-6k for qemu-devel@nongnu.org; Mon, 28 Nov 2016 06:19:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40624) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBJyO-0001oQ-UA for qemu-devel@nongnu.org; Mon, 28 Nov 2016 06:19:49 -0500 Date: Mon, 28 Nov 2016 11:19:44 +0000 From: Stefan Hajnoczi Message-ID: <20161128111944.GB6411@stefanha-x1.localdomain> References: <1480073296-6931-1-git-send-email-vsementsov@virtuozzo.com> <20161127191714.7wrvzbx7zpotad22@grep.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <20161127191714.7wrvzbx7zpotad22@grep.be> Subject: Re: [Qemu-devel] [Nbd] [PATCH v3] doc: Add NBD_CMD_BLOCK_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst Cc: Vladimir Sementsov-Ogievskiy , nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, kwolf@redhat.com, den@openvz.org, pborzenkov@virtuozzo.com, mpa@pengutronix.de, pbonzini@redhat.com --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 27, 2016 at 08:17:14PM +0100, Wouter Verhelst wrote: > Quickly: the reason I haven't merged this yes is twofold: > - I wasn't thrilled with the proposal at the time. It felt a bit > hackish, and bolted onto NBD so you could use it, but without defining > everything in the NBD protocol. "We're reading some data, but it's not > about you". That didn't feel right > > - There were a number of questions still unanswered (you're answering a > few below, so that's good). >=20 > For clarity, I have no objection whatsoever to adding more commands if > they're useful, but I would prefer that they're also useful with NBD on > its own, i.e., without requiring an initiation or correlation of some > state through another protocol or network connection or whatever. If > that's needed, that feels like I didn't do my job properly, if you get > my point. The out-of-band operations you are referring to are for dirty bitmap management. (The goal is to read out blocks that changed since the last backup.) The client does not access the live disk, instead it accesses a read-only snapshot and the dirty information (so that it can copy out only blocks that were written). The client is allowed to read blocks that are not dirty too. If you want to implement the whole incremental backup workflow in NBD then the client would first have to connect to the live disk, set up dirty tracking, create a snapshot export, and then connect to that snapshot. That sounds like a big feature set and I'd argue it's for the control plane (storage API) and not the data plane (NBD). There were discussions about transferring the dirty information via the control plane but it seems more appropriate to it in the data plane since it is block-level information. I'm arguing that the NBD protocol doesn't need to support the incremental backup workflow since it's a complex control plane concept. Being able to read dirty information via NBD is useful for other block backup applications, not just QEMU. It could be used for syncing LVM volumes across machines, for example, if someone implements an NBD+LVM server. Another issue with adding control plane operations is that you need to begin considering privilege separation. Should all NBD clients be able to initiate snapshots, dirty tracking, etc or is some kind of access control required to limit certain commands? Not all clients require the same privileges and so they shouldn't have access to the same set of operations. Stefan --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYPBLQAAoJEJykq7OBq3PIX44H/Rli4r5owpFbJkU2w8cGQyf3 zwoe/aeBF5SNDoBoppErJ6wPgtRNnVN1uV07M303YJ+T8DzURAvJPGpCHyNR+K/c G30SX4/hzVOY4FY3hIbk2zTaMm5WRSEhpSlAcqOBt7hE07RqOwgfbb7QiiFAZZRW 0otCX4HZTXlFvXM44vxuxt5bR2pQqv5d48D4TYxJVnpvv/deipe8kC1eXMDtfGTK vD4tNc8gapCrk3s9c4jgJ7AiEhvmrn4Z6vFhk+LrUn8jgFK6+Nnyj4TnA72CPmuD hNIpSvULpL7v91jKuQJHdY5+vlGFetYR/ZGJcRe5HH1KFvsLRALtWv6l4XNv0o4= =4T9i -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG--