From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anAns-0007Zd-Tv for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:08:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anAnn-00062a-UN for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:08:52 -0400 Received: from mail-am1on0106.outbound.protection.outlook.com ([157.56.112.106]:50255 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anAnn-00062U-5Q for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:08:47 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <7AD0DCB1-1868-4AAD-A03D-C976A728DD75@alex.org.uk> <5702C1AB.8020601@redhat.com> <5702C65A.7040101@openvz.org> <48C4F50D-E826-40E7-BB4F-21F9D1A67386@alex.org.uk> From: "Denis V. Lunev" Message-ID: <5702C9BE.8050307@openvz.org> Date: Mon, 4 Apr 2016 23:08:30 +0300 MIME-Version: 1.0 In-Reply-To: <48C4F50D-E826-40E7-BB4F-21F9D1A67386@alex.org.uk> 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:03 PM, Alex Bligh wrote: > On 4 Apr 2016, at 20:54, Denis V. Lunev wrote: > >> for now and for QEMU we want this to expose accumulated dirtiness >> of the block device, which is collected by the server. Yes, this requires >> external coordination. May be this COULD be the part of the protocol, >> but QEMU will not use that part of the protocol. >> >> saying about dirtiness, we would soon come to the fact, that >> we can have several dirtiness states regarding different >> lines of incremental backups. This complexity is hidden >> inside QEMU and it would be very difficult to publish and >> reuse it. > So qemu-nbdserver has some idea of 'dirtiness', and you want > to publish that, and the consumer is qemu (and only qemu), > because only qemu knows what 'dirtiness' means in the > sense the server provides it? > > I've nothing against helping qemu out here (having > contributed to qemu myself), but perhaps it might be better then, > rather than call it 'dirtiness' to make it some named attribute > for private client/server communication. > > This again makes me think this should be a different > command from something which is obviously useful and > comprehensible to more than one server/client (i.e. > allocation). > original design of this command has used 16 number to specify the NUMBER of the bitmap which was exported by the server. We have reserved number 0 for 'used' bitmap, i.e. bitmap of allocated blocks and number 1 for 'dirty' bitmap. Though we can skip specification of the belonging of any number except '0' and put them to server-client negotiations. Or we could reserve '1' for dirtiness state as server-client agrees and allow other applications to register their own bitmaps as the deserve to. Why not to do things this original way? Den