From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj1ws-0003EM-4y for qemu-devel@nongnu.org; Thu, 24 Mar 2016 05:53:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj1wo-0004uL-3Q for qemu-devel@nongnu.org; Thu, 24 Mar 2016 05:53:02 -0400 Received: from barbershop.grep.be ([89.106.240.122]:38304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj1wn-0004u8-Qq for qemu-devel@nongnu.org; Thu, 24 Mar 2016 05:52:58 -0400 Date: Thu, 24 Mar 2016 10:33:15 +0100 From: Wouter Verhelst Message-ID: <20160324093315.GA2870@grep.be> References: <1458742562-30624-1-git-send-email-den@openvz.org> <1458742562-30624-3-git-send-email-den@openvz.org> <20160323175834.GC2467@grep.be> <20160324084318.GC24831@phobos.sw.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20160324084318.GC24831@phobos.sw.ru> 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: Pavel Borzenkov Cc: nbd-general@lists.sourceforge.net, Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini , "Denis V. Lunev" --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 24, 2016 at 11:43:18AM +0300, Pavel Borzenkov wrote: > On Wed, Mar 23, 2016 at 06:58:34PM +0100, Wouter Verhelst wrote: > > On Wed, Mar 23, 2016 at 05:16:02PM +0300, Denis V. Lunev wrote: > > > + 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 stat= es > > > + 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 particu= lar NBD > > > + server operation MUST NOT make any assumption on the meaning of = the > > > + NBD_STATE_DIRTY or NBD_STATE_CLEAN states. > >=20 > > 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. > >=20 > > 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 > What I was trying to say with this sentence is that without knowing what > is currently going on on the server side, the DIRTY state has no > meaning. If we are doing incremental backup DIRTY state might represent b= locks > that have changed since last backup. For mirroring - blocks that are yet > to be migrated. And for the same block device different sets of DIRTY > ranges might be returned in response to this command. Basically, the > meaning of DIRTY depends on the context.=20 >=20 > Should I state in the spec, that the meaning of DIRTY state is > implementation-specific? I see that NBD_REP_SERVER already uses this > approach. That's still meaningless without a way for the client to detect what the server-side implementation actually is. The protocol doesn't have that. This is okay for NBD_REP_SERVER, because the extra information there is *also* defined to be "UTF-8 encoded data suitable for direct display to a human being", which means it just allows the server to pass on some extra info (e.g., qemu could use it to state whether it's in use by a live VM, or what the backend storage pool is, etc), but the data there is not going to be critical. For this proposed message, however, that is not the case; the whole point of this part of your proposal seems to be to tell the client whether some part of the export is "dirty" or not. Now I'm not saying we need to fully define what it means for a part of the backend to be "dirty" or not. It's okay to leave part of the meaning in the dark, leaving that implementation-defined. But saying "must not make any assumption" basically means "give me some random metadata, and I'll throw it away then because there's nothing I can do with it". Alternatively, we could define more states than just "dirty" and "clean", and have those be more strictly defined than what your current proposal says. --=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 --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJW87RbAAoJEMKUD5Ub3wqd3s0QAIlt/jO5+qiD15qgZ/jczFwS lPnmEthoBlZEs2+9qyENpe/3xuktSwBXhNZA/5iewQKhdTiHO58nWXw9A2sSd7gE sizpBGLd5xuZikLM6c2E8PrExmrO8Ot3Ne3QKwCIQcRQVqqLSVnJ8wan3VD7hZ+T fB5e/xEW+f/7wu/iCY9Ve9L6X8FC5l6UFGBsyGnd+6qDMi3rMv2AVq2BEUCc0LKs gSu5l5fvaKbdMrRm0XXe+wvqZQvPhWZ8gj9Ib+sn8CBXoreyYNPD5O7O21Y1ThWY kb4GF6Vb4vJzVowSqQPU5hTpDbX7hxS8C0NKV9spPXvFRknOteOPwm3Tj8Fqqulm UB3tPgj2bYnoEbuAIlpC8mfqTq1AUv7/mDAC3LO5kO60X0GRvI0SrPnt9u+8p95o 5p/F0rhrDa87UdXJXkVfUEA9ZU8/GAG2yJxQc3icmP0Jd3Ba02qgdFe02lZmw6Nu J/NaiMxC6/iKZD4VLbkkUWwAyL0cwcrtcZk/uuJ5BCmjnCX8+i+Ogf4ztE9lJ3RO BXkxXyEfudqmxyn77jV49qrPwxvvB+Si/qBKSmX9BZAnDD5wS2hYoP5iqEAKaG/c Bn00tOZDjfvCmc7wVC+i78iklRF79x074hkPzBM+M/tJB3ZVL/QYyVwJGrM3Eukb m1LRLtkJASDNHGV+HKU0 =V1/I -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl--