From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anAjh-0004HH-Su for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:04:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anAje-0004n2-MK for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:04:33 -0400 Received: from mail-db3on0133.outbound.protection.outlook.com ([157.55.234.133]:46052 helo=emea01-db3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anAje-0004mq-43 for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:04:30 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <7AD0DCB1-1868-4AAD-A03D-C976A728DD75@alex.org.uk> <5702C1AB.8020601@redhat.com> From: "Denis V. Lunev" Message-ID: <5702C8C3.1050300@openvz.org> Date: Mon, 4 Apr 2016 23:04:19 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: Alex Bligh , Eric Blake Cc: "nbd-general@lists.sourceforge.net" , Kevin Wolf , "qemu-devel@nongnu.org" , Pavel Borzenkov , "Stefan stefanha@redhat. com" , Wouter Verhelst , Paolo Bonzini On 04/04/2016 10:58 PM, Alex Bligh wrote: > Eric, > >> Nothing requires the two uses to report at the same granularity. THe >> NBD_REPLY_TYPE_BLOCK_STATUS allows the server to divide into descriptors >> as it sees fit (so it could report holes at a 4k granularity, but >> dirtiness only at a 64k granularity) - all that matters is that when all >> the descriptors have been sent, they total up to the length of the >> original client request. So by itself, granularity does not require >> another command. > Sure, but given you can't report dirtiness without also reporting > allocation, if they are are at different blocksize I'd rather they > were in different commands, because otherwise the code to report > block size needs to work at two different granularities. > 'dirty' could come after the data was 'trimmed' from the region! thus we could have dirty unallocated data. >> At this point, I was just trying to rebase the proposal as originally >> made by Denis and Pavel; perhaps they will have more insight on how they >> envisioned using the command, or on whether we should try harder to make >> this more of a two-way protocol (where the client can tell the server >> when to mark something as clean, or when to start tracking whether >> something is dirty). > I'm not sure it needs to be a two way protocol (see my strawman) but > I'd like to know it's at least possibly useful. > > -- > Alex Bligh > > > >