RE: [PATCH] proto: add xNBD command NBD_CMD_CACHE to the spec
Hi,
> +* `NBD_CMD_CACHE` (5)
> +
> + Cache request. Implies server to perform some action to speed-up
> + further read requests to the area specified by *offset* and
> + *length*. However, performance gain is not guaranteed and depends on
> + server implementation.
It may also speed up future write requests.
It depends on how a server program supporting the NBD protocol is implemented.
For xNBD, a future write request (not aligned to a block-size boundary) will get performance gain.
> +
> + If an error occurs, the server MUST set the appropriate error code
> + in the error field. However failure on this operation doesn't mean
> + that further read requests on this area will fail.
> +
> + A client MUST NOT send a cache request unless `NBD_FLAG_SEND_CACHE`
> + was set in the transmission flags field.
> +
When receiving an NBD_CMD_CACHE request, a xNBD server running in the proxy mode retrieves the disk blocks of the specified area from a remote NBD server and saves them in the local storage of the xNBD server.
The reply message of NBD_CMD_CACHE does not have disk data in its payload.
Best,
Takahiro
________________________________________
差出人: Wouter Verhelst <w@uter.be>
送信日時: 2018年4月1日 22:15
宛先: Vladimir Sementsov-Ogievskiy
CC: nbd@other.debian.org; eblake@redhat.com; alex@alex.org.uk; pbonzini@redhat.com; den@openvz.org; 広渕崇宏
件名: Re: [PATCH] proto: add xNBD command NBD_CMD_CACHE to the spec
So, I haven't replied to this yet because I would like some feedback
from Takahiro first, but so far that hasn't been forthcoming.
Takahiro-san, care to comment? The virtuozzo people would like to
implement something of which I think the requirements are very similar
to your NBD_CMD_CACHE command, and are therefore proposing to add the
specification of your extra command to the NBD protocol spec; however, I
don't want to approve that unless you've reviewed it, since I don't
really know all the ins and outs of what you've implemented, and I would
hate to add something to the spec based on what you do but slightly
incompatible with it because I missed something -- that would suck.
Thanks for your feedback,
On Mon, Mar 26, 2018 at 07:10:49PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>
> Hi all.
>
> The actual usage case, as already described in mailing list:
>
> some kind of VM restore from backup:
>
> +---------- VM --------------+
> | |
> | guest |
> | | |
> | local disk -- (NBD server)<----CACHE-------+(third party NBD client)
> | | |
> | (NBD client*)<----------------(data)-------+(NBD server) -- [VM backup]
> | |
> +----------------------------+
>
> - copy-on-read is set up between "local disk" and "NBD client*"
> - when guest read block and there is no corresponding block in the local
> disk it is read from the NBD client*, and saved in the local disk
> - when guest writes something, it is written into the local disk
> - on CMD_CACHE, if there is no corresponding block in local disk, it is
> read from NBD client and saved in the local disk
> - on CMD_CACHE, if there is corresponding block in local disk - do nothing
>
>
> doc/proto.md | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/doc/proto.md b/doc/proto.md
> index c7803e0..73ce5de 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -897,6 +897,7 @@ The field has the following format:
> the export.
> - bit 9, `NBD_FLAG_SEND_RESIZE`: defined by the experimental `RESIZE`
> [extension](https://github.com/NetworkBlockDevice/nbd/blob/extension-resize/doc/proto.md).
> +- bit 10, `NBD_FLAG_SEND_CACHE`: exposes support for `NBD_CMD_CACHE`.
>
> Clients SHOULD ignore unknown flags.
>
> @@ -1632,6 +1633,20 @@ The following request types exist:
> A client MUST NOT send a trim request unless `NBD_FLAG_SEND_TRIM`
> was set in the transmission flags field.
>
> +* `NBD_CMD_CACHE` (5)
> +
> + Cache request. Implies server to perform some action to speed-up
> + further read requests to the area specified by *offset* and
> + *length*. However, performance gain is not guaranteed and depends on
> + server implementation.
> +
> + If an error occurs, the server MUST set the appropriate error code
> + in the error field. However failure on this operation doesn't mean
> + that further read requests on this area will fail.
> +
> + A client MUST NOT send a cache request unless `NBD_FLAG_SEND_CACHE`
> + was set in the transmission flags field.
> +
> * `NBD_CMD_WRITE_ZEROES` (6)
>
> A write request with no payload. *Offset* and *length* define the
> @@ -1679,9 +1694,6 @@ The following request types exist:
> maintainer of this document, so that these messages can be listed here
> to avoid conflicting implementations.
>
> - Currently one such message is known: `NBD_CMD_CACHE`, with type set to
> - 5, implemented by xnbd.
> -
> #### Error values
>
> The error values are used for the error field in the reply message.
> --
> 2.11.1
>
>
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: