On 08/17/2018 08:49 AM, Vladimir Sementsov-Ogievskiy wrote:
BDRV_SECTOR_SIZE : 1; + /* minimum - 1 for back-compat, or actual if client will obey it. */ + if (client->opt == NBD_OPT_INFO || blocksize) { + sizes[0] = blk_get_request_alignment(exp->blk); + } else { + sizes[0] = 1; + } /* preferred - Hard-code to 4096 for now. * TODO: is blk_bs(blk)->bl.opt_transfer appropriate? */ sizes[1] = 4096;Here, what about dirty bitmap export through BLOCK_STATUS? Could it's granularity be less than request_alignment? Shouldn't we handle it somehow?
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, which means you always set a multiple of bits per action; when reading back the dirty bitmap to report over NBD_CMD_BLOCK_STATUS, you'll never encounter a change in bit status except on alignment boundaries (based on how the bits were written), and thus what NBD reports will still be aligned to the advertised minimum size, rather than the smaller bitmap granularity.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
