On 04/19/2018 09:43 AM, Eric Blake wrote: > > 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? Taking it one step further: I don't know whether xNBD is well-behaved on a call to NBD_CMD_FLAG with unknown NBD_CMD_FLAG_* bits set (that is, the NBD spec recommends that unknown flags should be rejected with EINVAL, but xNBD might be silently ignoring unknown flags and behaving with the WILLNEED behavior). But if we like the idea of the NBD spec treating NBD_CMD_CACHE as a thin wrapper around posix_fadvise() semantics, then we should expose NBD_CMD_FLAG_* values for each of the posix_fadvise() advice flags that might be useful to expose (all of those flags are advisory; any implementation is free to ignore a given advice, and/or return EINVAL for an advice it can't implement); then further document that a client SHOULD NOT send NBD_CMD_FLAG_* advice unless the server advertised NBD_FLAG_SEND_CACHE (so that we never pessimize a client that sends the DONTNEED flag if xNBD silently treated that as a WILLNEED advice), but that any server that does advertise CACHE support will sanely behave for all flags. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature