[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? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature