On Wed, Feb 21, 2024 at 02:35:25PM -0600, Eric Blake wrote:
NBD_OPT_GO either advertises the actual size (possibly with an
override from the command line or config file), the value OFFT_MAX (if
multitree or F_WAIT means computing a real size would take too long),
or the value UINT64_MAX (if size_autodetect fails, such as when fd is
non-seekable); the only time it ever advertises a size of 0 is when it
is serving a regular file that really is empty.
On the other hand, NBD_OPT_INFO had been blindly advertising 0 no
matter what. While we can't always compute a real size, we can do a
lot better by advertising the same sentinels as NBD_OPT_GO.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
Rich has already chimed in on my question about what size SHOULD
nbd-server report when NBD_OPT_GO wants to list an indeterminate size;
if we start changing the spec, then this may be incomplete or need
tweaking. Here, I only tackled the simple case of a single-file (or
block device) export; there are multifile cases where NBD_OPT_GO still
reports a more accurate number than this. There's also the question
of whether we want to address the information leak (right now, the
code can succeed on NBD_OPT_INFO even when it will later fail for
NBD_OPT_GO because the client is not authorized to used the export).
I think that should probably be fixed, too. If the client is not
authorized to use the export, I think we should also not leak
information about the export.
Second thought: does it make sense to see if the overlap of what
probe_client does could be extracted from commit_client, with
commit_client then just calling probe_client and then only doing the
other things it still needs to do? Otherwise this feels like duplicate
code, and I don't like duplicate code :)
--
w(a)uter.{be,co.za}
wouter(a){grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.