Re: [PATCH] proto: add xNBD command NBD_CMD_CACHE to the spec
On Wed, Apr 11, 2018 at 05:30:02PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 03.04.2018 21:03, Wouter Verhelst wrote:
> > 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.
>
> What do you mean? Add a paragraph, describing, what xNBD do on
> NBD_CMD_CACHE, like a note about specific implementation?
Yes, that's what I meant. But...
> Or just add last sentence? But we don't write this for other command, as the
> only exclusion is CMD_READ, which is clean..
... also a good point. Let's just not then :-)
--
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: