From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anAsf-0001fe-2L for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:13:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anAsa-0007LE-31 for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:13:49 -0400 Received: from mail-am1on0116.outbound.protection.outlook.com ([157.56.112.116]:48604 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anAsZ-0007Kr-Mr for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:13:43 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <7AD0DCB1-1868-4AAD-A03D-C976A728DD75@alex.org.uk> <5702C1AB.8020601@redhat.com> <5702C8C3.1050300@openvz.org> From: "Denis V. Lunev" Message-ID: <5702CAEA.4060804@openvz.org> Date: Mon, 4 Apr 2016 23:13:30 +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 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 11:08 PM, Alex Bligh wrote: > On 4 Apr 2016, at 21:04, Denis V. Lunev wrote: > >>> 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. > Let me rephrase. > > Under the current proposal it is not possible to report whether or > not a region is dirty without also reporting whether or not it > is allocated. As these two concepts exist at potentially > different block sizes, the code to support reporting on allocation > must now be able to run both at the allocation blocksize and > the dirtiness blocksize, which is going to be a pain. > > If these were two different commands, they could each run at their > natural block size. > could you look into V1 of this? As far as I remember that text we have had a number in request specifying which bitmap to query and the server should reply with one bitmap at a time. Would this work for you?