Re: [PATCH v4] doc: Add alternate trim/zero limits
On 10/2/18 10:31 AM, Vladimir Sementsov-Ogievskiy wrote:
Hmm, Eric, what are the plans about this?
Now in upstream discard, write-zeros and block-status are limited in
client to 32m by default which is too slow.
Can we make some minimal specification change to drop these strict
limitations?
Elsewhere in the thread, back in May:
So, now we have two very similar options, and in realization - two almost identical code paths.
Are we going to add similar limits for BLOCK_STATUS? and for CACHE? I have an idea: what about some kind of universal option for it? Something like
option INFO_CMD_SIZE: specific limits for command:
uint16_t command
uint32_t min_block
uint32_t max_block
and server can send several such options, client can request them in some generic way. Most of semantics for these additional limits are common, so it will simplify both documentation and realization.
We already document "A particular information type SHOULD only appear once for a given export unless documented otherwise." - but this would indeed be a case where we could document otherwise.
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? 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.
It's still on my todo list to propose an alternative wording along with
a qemu implementation, for the v5 posting of this topic. However, it
likely won't happen until after KVM Forum later this month.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Reply to: