Re: [RFC PATCH] server: Advertise nicer size for NBD_OPT_INFO

[Wouter Verhelst <w@uter.be>]

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@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@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.