On 05/22/2018 10:33 AM, Vladimir Sementsov-Ogievskiy wrote:
02.05.2018 00:13, Eric Blake wrote:
The NBD spec is clarifying [1] that a server may want to advertise
different limits for READ/WRITE (in our case, 32M) than for
TRIM/ZERO (in our case, nearly 4G). Implement the client
side support for these alternate limits, by always requesting
the new information (a compliant server must ignore the
request if it is unknown), and by validating anything reported
by the server before populating the block layer limits.
I still need to do a v2 of this series based on feedback from the NBD
list, but answering your question in the meantime:
bs->bl.request_alignment = min ? min : BDRV_SECTOR_SIZE;
- bs->bl.max_pdiscard = max;
- bs->bl.max_pwrite_zeroes = max;
+ if (s->info.max_trim) {
+ bs->bl.max_pdiscard = MIN(s->info.max_trim,
BDRV_REQUEST_MAX_BYTES);
+ } else {
+ bs->bl.max_pdiscard = max;
+ }
+ bs->bl.pdiscard_alignment = s->info.min_trim;
+ if (s->info.max_zero) {
+ bs->bl.max_pwrite_zeroes = MIN(s->info.max_zero,
+ BDRV_REQUEST_MAX_BYTES);
+ } else {
+ bs->bl.max_pwrite_zeroes = max;
+ }
+ bs->bl.pwrite_zeroes_alignment = s->info.min_zero;
bs->bl.max_transfer = max;
Should not max_transfer be updated too? Looks like it limits all
requests, is it right?
max_transfer affects read and write requests, but not write_zero
requests (where max_pwrite_zeroes is used instead) or trim requests
(where max_pdiscard is used instead). Which is precisely the semantics
we want - the NBD extension is mirroring the fact that qemu already has
a way to track independent limits for trim/zero that can be larger than
the normal limits for read/write, because trim/zero do not involve a
transfer of a large data buffer.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
