Hi,
On Mon, Apr 02, 2018 at 07:47:53AM +0000, 広渕崇宏 wrote:
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.
Okay, so make that "speed up further access to the area specified
by...". We also should make it implementation-defined whether this is a
write-through or a write-back cache, I think, and which algorithm and/or
protocol the server uses to realize that cache (e.g., it may be a proxy
for another disk access protocol).
+ 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.
This presumably conflicts with xNBD, which does send out CMD_CACHE
without that flag (at least, the flag is not reserved, so...). However,
I do think that it's better to negotiate the cache command before trying
to use it, so I would just append the following to your proposed wording:
However, implementations already exist that do send out NBD_CMD_CACHE
without negotiating its use through NBD_FLAG_SEND_CACHE; therefore,
implementations desiring maximum portability should allow for this
possibility.
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.
Good point, thanks; we should add that too.