From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anDbq-0005AZ-Kd for qemu-devel@nongnu.org; Mon, 04 Apr 2016 19:08:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anDbl-000353-LM for qemu-devel@nongnu.org; Mon, 04 Apr 2016 19:08:38 -0400 Received: from barbershop.grep.be ([89.106.240.122]:47555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anDbl-00034y-Fv for qemu-devel@nongnu.org; Mon, 04 Apr 2016 19:08:33 -0400 Date: Tue, 5 Apr 2016 01:08:17 +0200 From: Wouter Verhelst Message-ID: <20160404230817.GC32049@grep.be> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5702C65A.7040101@openvz.org> 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: "Denis V. Lunev" Cc: "nbd-general@lists.sourceforge.net" , Kevin Wolf , "Stefan stefanha@redhat. com" , "qemu-devel@nongnu.org" , Pavel Borzenkov , Alex Bligh , Paolo Bonzini On Mon, Apr 04, 2016 at 10:54:02PM +0300, Denis V. Lunev wrote: > 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. How about this then. A reply to GET_BLOCK_STATUS containing chunks of this: 32-bit length 32-bit "snapshot status" if bit 0 in the latter field is set, that means the block is allocated on the original device if bit 1 is set, that means the block is allocated on the first-level snapshot if bit 2 is set, that means the block is allocated on the second-level snapshot etc If all flags are cleared, that means the block is not allocated (i.e., is a hole) and MUST read as zeroes. If a flag is set at a particular level X, that means the device is dirty at the Xth-level snapshot. If at least one flag is set for a region, that means the data may read as "not zero". The protocol does not define what it means to have multiple levels of snapshots, other than: - Any write command (WRITE or WRITE_ZEROES) MUST NOT clear or set the Xth level flag if the Yth level flag is not also cleared at the same time, for any Y > X - Any write (as above) MAY set or clear multiple levels of flags at the same time, as long as the above holds Having a 32-bit snapshot status field allows for 32 levels of snapshots. We could switch length and flags to 64 bits so that things continue to align nicely, and then we have a maximum of 64 levels of snapshots. (I'm not going to write this up formally at this time of night, but you get the general idea) -- < 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