1. 13 10月, 2017 2 次提交
  2. 01 8月, 2017 1 次提交
  3. 18 7月, 2017 1 次提交
  4. 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
  5. 10 7月, 2017 1 次提交