[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 4/6] nbd/server: implement dirty bitmap expor

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v5 4/6] nbd/server: implement dirty bitmap export
Date: Wed, 20 Jun 2018 10:58:32 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/20/2018 10:43 AM, Eric Blake wrote:
On 06/20/2018 06:24 AM, Eric Blake wrote:

+/* Set several extents, describing region of given @length with given @flags.
+ * Do not set more than @nb_extents, return number of set extents.
+ */
+static unsigned add_extents(NBDExtent *extents, unsigned nb_extents,
+                            uint64_t length, uint32_t flags)
+    unsigned i = 0;
+    uint32_t max_extent = QEMU_ALIGN_DOWN(INT32_MAX, BDRV_SECTOR_SIZE);

This is too small of a granularity wrong when the server advertised 4k alignment during NBD_OPT_GO; it should probably refer to bs->bl.request_alignment.

In fact, we can just use INT32_MAX. The dirty bitmap has a granularity at least as large as the sector size, but no smaller than the request_alignment. We don't have to worry about alignment here, as the extents will already be naturally aligned when converting from the bitmap into extents in the caller.

Oh, I see. The NBD protocol can only ask for a length of up to 32 bits, but if you learn via bitmap query that the entire rest of the image has the same state, you can indeed call add_extents() with a value larger than 32 bits, that needs to be fragmented back down into sub-32-bit chunks. INT32_MAX isn't quite right, but rounding may still pick the wrong granularity on an export with 4k alignment; however, INT32_MAX + 1U is just fine, and unlikely to run into alignment issues.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]