Re: [PATCH v4] doc: Add alternate trim/zero limits
On 05/03/2018 10:45 AM, Vladimir Sementsov-Ogievskiy wrote:
Do you envision a server that needs to have independent limits for
CACHE and/or BLOCK_STATUS beyond the usual limits for READ, where
advertising alternative limits is worthwhile?
CACHE: our planned usage (managed copy-on-read process) surely will
benefit if client will not be restricted on caching request size.
for BLOCK_STATUS, when we use it in some copying process, it's good to
query large region, to be able to use fast path in case of zero area (I
don't remember, did we finally allowed last chunk of BLOCK_STATUS to
exceed requested region?)
We talked about that. It is NOT currently worded in the spec that way,
but I think the qemu implementation (which is the only known
implementation of BLOCK_STATUS right now) will tolerate it, so now would
be a good time to wordsmith that addition into the standard.
But the idea of having a single reusable info that documents
per-command limits may be worth the effort, so I'll try a v5 of both
this patch and of the qemu proof-of-concept implementation along those
lines, so that we can compare the two approaches.
Note, however, that if you only have a single command, a client can
ONLY request NBD_INFO_CMD_SIZE once; it is then relying on the server
to reply with as many per-command limits as the server wants, and
can't specifically request alternative limits on a given command.
Hmm, yes. We can either add a way to request an option with a parameter
or live with it. But it don't look like a real problem, until we don't
have thousands of commands)
I don't see it being a problem - the only reason a client would request
it is to let the server know that "yes, I'm interested in any
per-command alternative limits you can tell me", knowing that the server
does not have to reply; and a server can send the limits whether or not
the client requested them.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Reply to: