15.11.2019 20:58, Eric Blake wrote: > On 11/15/19 8:14 AM, Vladimir Sementsov-Ogievskiy wrote: >> This brings async request handling and block-status driven chunk sizes >> to backup out of the box, which improves backup performance. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >> --- > >> +++ b/qapi/block-core.json >> @@ -1455,6 +1455,12 @@ >> # above node specified by @drive. If this option is not >> given, >> # a node name is autogenerated. (Since: 4.2) >> # >> +# @x-max-workers: maximum of parallel requests for static data backup. This >> +# doesn't influence copy-before-write operations. (Since: >> 4.3) >> +# >> +# @x-max-chunk: maximum chunk length for static data backup. This doesn't >> +# influence copy-before-write operations. (Since: 4.3) > > The next release is 5.0, not 4.3. > > Is there a reason to keep these experimental for a while? For example, are > there potential changes to the interface that might affect how it gets used? > Or should we drop the x- prefix and add this outright in 5.0? >
Hmm, I added these options to satisfy some very conservative iotests. Still, they may be meaningful for user too. The only real doubt is that actually they are options of block-copy, not backup job. And to not finish up with adding such parameters to each block-job, it may be better to combine them into a structure.. Or may be not. -- Best regards, Vladimir