1. 21 6月, 2018 1 次提交
  2. 02 4月, 2018 1 次提交
  3. 02 3月, 2018 1 次提交
  4. 08 1月, 2018 1 次提交
    • E
      nbd/server: Implement sparse reads atop structured reply · 418638d3
      Eric Blake 提交于
      The reason that NBD added structured reply in the first place was
      to allow for efficient reads of sparse files, by allowing the
      reply to include chunks to quickly communicate holes to the client
      without sending lots of zeroes over the wire.  Time to implement
      this in the server; our client can already read such data.
      
      We can only skip holes insofar as the block layer can query them;
      and only if the client is okay with a fragmented request (if a
      client requests NBD_CMD_FLAG_DF and the entire read is a hole, we
      could technically return a single NBD_REPLY_TYPE_OFFSET_HOLE, but
      that's a fringe case not worth catering to here).  Sadly, the
      control flow is a bit wonkier than I would have preferred, but
      it was minimally invasive to have a split in the action between
      a fragmented read (handled directly where we recognize
      NBD_CMD_READ with the right conditions, and sending multiple
      chunks) vs. a single read (handled at the end of nbd_trip, for
      both simple and structured replies, when we know there is only
      one thing being read).  Likewise, I didn't make any effort to
      optimize the final chunk of a fragmented read to set the
      NBD_REPLY_FLAG_DONE, but unconditionally send that as a separate
      NBD_REPLY_TYPE_NONE.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20171107030912.23930-2-eblake@redhat.com>
      Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      418638d3
  5. 10 11月, 2017 2 次提交
    • E
      nbd/server: Fix structured read of length 0 · ef8c887e
      Eric Blake 提交于
      The NBD spec was recently clarified to state that a read of length 0
      should not be attempted by a compliant client; but that a server must
      still handle it correctly in an unspecified manner (that is, either
      a successful no-op or an error reply, but not a crash) [1].  However,
      it also implies that NBD_REPLY_TYPE_OFFSET_DATA must have a non-zero
      payload length, but our existing code was replying with a chunk
      that a picky client could reject as invalid because it was missing
      a payload (our own client implementation was recently patched to be
      that picky, after first fixing it to not send 0-length requests).
      
      We are already doing successful no-ops for 0-length writes and for
      non-structured reads; so for consistency, we want structured reply
      reads to also be a no-op.  The easiest way to do this is to return
      a NBD_REPLY_TYPE_NONE chunk; this is best done via a new helper
      function (especially since future patches for other structured
      replies may benefit from using the same helper).
      
      [1] https://github.com/NetworkBlockDevice/nbd/commit/ee926037Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20171108215703.9295-8-eblake@redhat.com>
      Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      ef8c887e
    • E
      nbd/client: Nicer trace of structured reply · 079d3266
      Eric Blake 提交于
      It's useful to know which structured reply chunk is being processed.
      Missed in commit d2febedb.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20171108215703.9295-4-eblake@redhat.com>
      Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      079d3266
  6. 31 10月, 2017 6 次提交
  7. 13 10月, 2017 2 次提交
  8. 01 8月, 2017 1 次提交
  9. 18 7月, 2017 1 次提交
  10. 14 7月, 2017 7 次提交
    • E
      nbd: Implement NBD_INFO_BLOCK_SIZE on client · 081dd1fe
      Eric Blake 提交于
      The upstream NBD Protocol has defined a new extension to allow
      the server to advertise block sizes to the client, as well as
      a way for the client to inform the server whether it intends to
      obey block sizes.
      
      When using the block layer as the client, we will obey block
      sizes; but when used as 'qemu-nbd -c' to hand off to the
      kernel nbd module as the client, we are still waiting for the
      kernel to implement a way for us to learn if it will honor
      block sizes (perhaps by an addition to sysfs, rather than an
      ioctl), as well as any way to tell the kernel what additional
      block sizes to obey (NBD_SET_BLKSIZE appears to be accurate
      for the minimum size, but preferred and maximum sizes would
      probably be new ioctl()s), so until then, we need to make our
      request for block sizes conditional.
      
      When using ioctl(NBD_SET_BLKSIZE) to hand off to the kernel,
      use the minimum block size as the sector size if it is larger
      than 512, which also has the nice effect of cooperating with
      (non-qemu) servers that don't do read-modify-write when
      exposing a block device with 4k sectors; it might also allow
      us to visit a file larger than 2T on a 32-bit kernel.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-10-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      081dd1fe
    • E
      nbd: Implement NBD_INFO_BLOCK_SIZE on server · 0c1d50bd
      Eric Blake 提交于
      The upstream NBD Protocol has defined a new extension to allow
      the server to advertise block sizes to the client, as well as
      a way for the client to inform the server that it intends to
      obey block sizes.
      
      Thanks to a recent fix (commit df7b97ff), our real minimum
      transfer size is always 1 (the block layer takes care of
      read-modify-write on our behalf), but we're still more efficient
      if we advertise 512 when the client supports it, as follows:
      - OPT_INFO, but no NBD_INFO_BLOCK_SIZE: advertise 512, then
      fail with NBD_REP_ERR_BLOCK_SIZE_REQD; client is free to try
      something else since we don't disconnect
      - OPT_INFO with NBD_INFO_BLOCK_SIZE: advertise 512
      - OPT_GO, but no NBD_INFO_BLOCK_SIZE: advertise 1
      - OPT_GO with NBD_INFO_BLOCK_SIZE: advertise 512
      
      We can also advertise the optimum block size (presumably the
      cluster size, when exporting a qcow2 file), and our absolute
      maximum transfer size of 32M, to help newer clients avoid
      EINVAL failures or abrupt disconnects on oversize requests.
      
      We do not reject clients for using the older NBD_OPT_EXPORT_NAME;
      we are no worse off for those clients than we used to be.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-9-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0c1d50bd
    • E
      nbd: Implement NBD_OPT_GO on client · 8ecaeae8
      Eric Blake 提交于
      NBD_OPT_EXPORT_NAME is lousy: per the NBD protocol, any failure
      requires the server to close the connection rather than report an
      error to us.  Therefore, upstream NBD recently added NBD_OPT_GO as
      the improved version of the option that does what we want [1]: it
      reports sane errors on failures, and on success provides at least
      as much info as NBD_OPT_EXPORT_NAME.
      
      [1] https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md
      
      This is a first cut at use of the information types.  Note that we
      do not need to use NBD_OPT_INFO, and that use of NBD_OPT_GO means
      we no longer have to use NBD_OPT_LIST to learn whether a server
      requires TLS (this requires servers that gracefully handle unknown
      NBD_OPT, many servers prior to qemu 2.5 were buggy, but I have patched
      qemu, upstream nbd, and nbdkit in the meantime, in part because of
      interoperability testing with this patch).  We still fall back to
      NBD_OPT_LIST when NBD_OPT_GO is not supported on the server, as it
      is still one last chance for a nicer error message.  Later patches
      will use further info, like NBD_INFO_BLOCK_SIZE.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-8-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8ecaeae8
    • E
      nbd: Implement NBD_OPT_GO on server · f37708f6
      Eric Blake 提交于
      NBD_OPT_EXPORT_NAME is lousy: per the NBD protocol, any failure
      requires us to close the connection rather than report an error.
      Therefore, upstream NBD recently added NBD_OPT_GO as the improved
      version of the option that does what we want [1], along with
      NBD_OPT_INFO that returns the same information but does not
      transition to transmission phase.
      
      [1] https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md
      
      This is a first cut at the information types, and only passes the
      same information already available through NBD_OPT_LIST and
      NBD_OPT_EXPORT_NAME; items like NBD_INFO_BLOCK_SIZE (and thus any
      use of NBD_REP_ERR_BLOCK_SIZE_REQD) are intentionally left for
      later patches.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-7-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      f37708f6
    • E
      nbd: Simplify trace of client flags in negotiation · 621c4f4e
      Eric Blake 提交于
      Simplify the tracing of client flags in the server, and return -EINVAL
      instead of -EIO if we successfully read but don't like those flags.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-5-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      621c4f4e
    • E
      nbd: Expose and debug more NBD constants · 3736cc5b
      Eric Blake 提交于
      The NBD protocol has several constants defined in various extensions
      that we are about to implement.  Expose them to the code, along with
      an easy way to map various constants to strings during diagnostic
      messages.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-4-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3736cc5b
    • E
      nbd: Don't bother tracing an NBD_OPT_ABORT response failure · 37ec36f6
      Eric Blake 提交于
      We really don't care if our spec-compliant reply to NBD_OPT_ABORT
      was received, so shave off some lines of code by not even tracing it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20170707203049.534-3-eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      37ec36f6
  11. 10 7月, 2017 1 次提交