qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 2/4] nbd/server: Advertise actual m


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 2/4] nbd/server: Advertise actual minimum block size
Date: Fri, 17 Aug 2018 10:11:28 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 08/17/2018 10:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Can you create a dirty bitmap with a granularity smaller than request_alignment?  I know you can configure dirty bitmap granularity independently from cluster size (in both directions: either smaller or larger than cluster size), but that it has a least a minimum lower bounds of 512.  You're probably right that we also want it to have a minimum lower bound of the request_alignment (if you're using a device with 4k minimum I/O, request_alignment would be 4k, and having a dirty bitmap any smaller than that granularity is wasted space).

On the other hand, I also think we're safe for this patch: even if you waste the space by creating a bitmap with too-small granularity, the actions that write bits into the bitmap will still be aligned to request_alignment,

Not quite right: nbd_export_bitmap searches through the backing chain for the bitmap, and it may correspond to the bds with smaller request_alignment.

Hmm. Interesting setup:

base (512-byte alignment, bitmap granularity) <- active (4k alignment)

so you're stating that exporting 'active' but with the 'bitmap' inherited from the backing chain from base means that the bitmap may have transitions in between the alignment advertised by active. Then it sounds like nbd/server.c:bitmap_to_extents() should be aware of that fact, and intentionally round up (anywhere that it finds a mid-alignment transition, treat the entire aligned region as dirty. It never hurts to mark more of the image dirty than necessary, but does hurt to expose a mid-alignment transition to an NBD client not expecting one).

--
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]