From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akq6m-00077W-Ki for qemu-devel@nongnu.org; Tue, 29 Mar 2016 05:38:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akq6h-0002Ok-KK for qemu-devel@nongnu.org; Tue, 29 Mar 2016 05:38:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akq6h-0002Og-Ci for qemu-devel@nongnu.org; Tue, 29 Mar 2016 05:38:39 -0400 Date: Tue, 29 Mar 2016 11:38:35 +0200 From: Kevin Wolf Message-ID: <20160329093835.GB4600@noname.redhat.com> References: <1458742562-30624-1-git-send-email-den@openvz.org> <1458742562-30624-3-git-send-email-den@openvz.org> <20160323175834.GC2467@grep.be> <56F3D5C7.9070007@redhat.com> <56F406E7.4010207@redhat.com> <56F408D6.2020002@redhat.com> <20160324155319.GK2870@grep.be> <56F4101D.7030603@redhat.com> <20160324160747.GF4310@noname.redhat.com> <20160324164747.GA2902@grep.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20160324164747.GA2902@grep.be> 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: Wouter Verhelst Cc: nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Stefan Hajnoczi , "Denis V. Lunev" , Paolo Bonzini --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 24.03.2016 um 17:47 hat Wouter Verhelst geschrieben: > On Thu, Mar 24, 2016 at 05:07:47PM +0100, Kevin Wolf wrote: > > Am 24.03.2016 um 17:04 hat Eric Blake geschrieben: > > > On 03/24/2016 09:53 AM, Wouter Verhelst wrote: > > > > On Thu, Mar 24, 2016 at 04:33:42PM +0100, Paolo Bonzini wrote: > > > >> On 24/03/2016 16:25, Eric Blake wrote: > > > >>>> However, let's make these bits, so that > > > >>>> > > > >>>> NBD_STATE_ALLOCATED (0x1), LBA extent is present on the block de= vice > > > >>>> NBD_STATE_ZERO (0x2), LBA extent will read as zeroes > > > >>> > > > >>> Should we flip the sense and call this NBD_STATE_UNALLOCATED (0 m= eans > > > >>> allocated, 1 means not present), so that an overall status of 0 i= s a > > > >>> safe default? > > > >> > > > >> Double negations are evil (and don't work the same in all language= s), so > > > >> I think it's a worse option. > > > >=20 > > > > I agree that a bit which says "unallocated" is confusing in that ma= nner, > > > > but that just means we need a better name (one that doesn't contain > > > > "un-" or "not") > > > >=20 > > > > I like the idea of having zero be the "sensible" default, although = I'm > > > > quite unable to come up with a better name myself. > > >=20 > > > NBD_STATE_TRIM, perhaps? (0 for present, 1 for trimmed or unallocated= ); > > > matches well that we have NBD_CMD_TRIM for requesting the creation of > > > such a state. > >=20 > > How about NBD_STATE_HOLE? >=20 > Both will work, although I like NBD_STATE_TRIM slightly better because > it indeed nicely references NBD_CMD_TRIM. I just thought that "trim" sounds more like an action than a status, and while the reason for a hole to exist can be a previous TRIM command, another option is that it's an area in an image that just has never been written to. In that case "trim" would be a misnomer. > However, I also think it should then be made clear that issuing > NBD_CMD_TRIM doesn't *require* that GET_BLOCK returns NBD_STATE_TRIM for > that region if the backend storage format dosn't support that, to avoid > confusion later on. Good point. That might be another reason for not calling the status "trim". Kevin --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJW+k0bAAoJEH8JsnLIjy/Wc2YQAJaAt6j2DS4DENmLGx7/wrMQ zNunFcIWtpspx1vZNeXD1uXnTjLPuwMdHUMxFhvGhH6vktN3a/qp9vhH08754cJz j4XShniCKuRJuZWGER55L9hw5EIdwObZyRDaXtk3vbZr8Yqr1u90Kt9mT7Adjtx/ PL+E7qLvDgGWEw8/qpiTwzi0g/jY1S9SzCsoNsoiJT+HSBPCI1RKOXS0pe+/fIBR 5uyyR4NquBzDJZ/0fAXPCXEOx8iM3HIi1coBMBVbc4RGxCF7PFI32DAt2dNFV6UQ z/1iVVEDAAhd7AgSOeRdra4LKL3etqVYqHa2nEU+NR04w/8FE2+qenQN6fYRVx7p g2yceJ12pQNEHQMpPdgV+eRiVn/63asTHSIpL1yi7IHqzbFAXNt0gwsN8gcIMu3q hjGMMkjShakbpbdgrV8cvWnD5Zu3u1vc80EylBhL4dSo0hvgUaWBG8K+OO4tYO1y XtGF0f1Njax7Z+g6AyYTpSA9XErrF61H2Wz3yocN4BlnjXWZ7peTSMbQ/shGsXYs zbERzu+jWBXHQN0nLaBy6pHox+Jl9qbauAXkrvgY2FbyrqPkk1879dPnZQnjUfsd gqJRmSMXw7x0TyFfWQ0f3U1iLCNDSPJ14RKvhFTag+eF7wn45712WqP1zq5UDEWL 4BZO5MyABP6wY9Ka0Ivw =gMzp -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+--