From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akst9-0006JT-Aj for qemu-devel@nongnu.org; Tue, 29 Mar 2016 08:36:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akst5-0000Bs-4v for qemu-devel@nongnu.org; Tue, 29 Mar 2016 08:36:51 -0400 Received: from barbershop.grep.be ([89.106.240.122]:34383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akst4-0000Ao-Ut for qemu-devel@nongnu.org; Tue, 29 Mar 2016 08:36:47 -0400 Date: Tue, 29 Mar 2016 11:53:54 +0200 From: Wouter Verhelst Message-ID: <20160329095354.GB6414@grep.be> References: <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> <20160329093835.GB4600@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329093835.GB4600@noname.redhat.com> 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: Kevin Wolf Cc: nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini , "Denis V. Lunev" On Tue, Mar 29, 2016 at 11:38:35AM +0200, Kevin Wolf wrote: > 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 device > > > > >>>> NBD_STATE_ZERO (0x2), LBA extent will read as zeroes > > > > >>> > > > > >>> Should we flip the sense and call this NBD_STATE_UNALLOCATED (0 means > > > > >>> allocated, 1 means not present), so that an overall status of 0 is a > > > > >>> safe default? > > > > >> > > > > >> Double negations are evil (and don't work the same in all languages), so > > > > >> I think it's a worse option. > > > > > > > > > > I agree that a bit which says "unallocated" is confusing in that manner, > > > > > but that just means we need a better name (one that doesn't contain > > > > > "un-" or "not") > > > > > > > > > > I like the idea of having zero be the "sensible" default, although I'm > > > > > quite unable to come up with a better name myself. > > > > > > > > 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. > > > > > > How about NBD_STATE_HOLE? > > > > 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. Point. It could be "TRIMMED" instead, I suppose. > > 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". Also a good point... -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12