Re: [PATCH] proto: add xNBD command NBD_CMD_CACHE to the spec
On Thu, Apr 19, 2018 at 09:43:47AM -0500, Eric Blake wrote:
> [adding Dan based on an IRC conversation]
>
> On 03/26/2018 11:10 AM, 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
> >
>
> This sounds somewhat like posix_fadvise(POSIX_FADV_WILLNEED). Do we
> want to also be able to expose posix_fadvise(POSIX_FADV_DONTNEED)
> semantics, perhaps by documenting NBD_CMD_FLAG_* fields to NBD_CMD_CACHE?
Not opposed to that per se, but I'm wary of adding more protocol
messages (and hence implied complications) unless we actually have a use
case for them.
I don't think we currently have a use case for DONTNEED messages? If we
do, then by all means. If not... I'd suggest to postpone that until we
actually do need it.
--
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: