1. 23 Dec, 2015 1 commit
  2. 19 Nov, 2015 1 commit
  3. 09 Nov, 2015 1 commit
  4. 28 Aug, 2015 5 commits
  5. 26 Aug, 2015 1 commit
  6. 03 Aug, 2015 1 commit
  7. 30 Jul, 2015 1 commit
    • Chris Leech's avatar
      iSCSI: let session recovery_tmo sysfs writes persist across recovery · 9c8108a4
      Chris Leech authored
      The iSCSI session recovery_tmo setting is writeable in sysfs, but it's
      also set every time a connection is established when parameters are set
      from iscsid over netlink.  That results in the timeout being reset to
      the default value after every recovery.
      
      The DM multipath tools want to use the sysfs interface to lower the
      default timeout when there are multiple paths to fail over.  It has
      caused confusion that we have a writeable sysfs value that seem to keep
      resetting itself.
      
      This patch adds an in-kernel flag that gets set once a sysfs write
      occurs, and then ignores netlink parameter setting once it's been
      modified via the sysfs interface.  My thinking here is that the sysfs
      interface is much simpler for external tools to influence the session
      timeout, but if we're going to allow it to be modified directly we
      should ensure that setting is maintained.
      Signed-off-by: default avatarChris Leech <cleech@redhat.com>
      Reviewed-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      9c8108a4
  8. 23 Jul, 2015 2 commits
  9. 14 Jul, 2015 1 commit
  10. 01 Jun, 2015 2 commits
  11. 18 May, 2015 1 commit
    • Bart Van Assche's avatar
      IB/srp: Add 64-bit LUN support · 985aa495
      Bart Van Assche authored
      The SCSI standard defines 64-bit values for LUNs. Large arrays
      employing large or hierarchical LUN numbers become more and more
      common. So update the SRP initiator to use 64-bit LUN numbers.
      See also Hannes Reinecke, commit 9cb78c16 ("scsi: use 64-bit LUNs"),
      June 2014.
      
      The largest LUN number that has been tested is 0xd2003fff00000000.
      
      Checked the following structure sizes with gdb:
      * sizeof(struct srp_cmd) = 48
      * sizeof(struct srp_tsk_mgmt) = 48
      * sizeof(struct srp_aer_req) = 36
      
      The ibmvscsi changes have been compile tested only (on a PPC system).
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: default avatarYann Droneaud <ydroneaud@opteya.com>
      Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
      Cc: Brian King <brking@linux.vnet.ibm.com>
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      985aa495
  12. 27 Apr, 2015 1 commit
    • Mike Christie's avatar
      SCSI: add 1024 max sectors black list flag · 35e9a9f9
      Mike Christie authored
      This works around a issue with qnap iscsi targets not handling large IOs
      very well.
      
      The target returns:
      
      VPD INQUIRY: Block limits page (SBC)
        Maximum compare and write length: 1 blocks
        Optimal transfer length granularity: 1 blocks
        Maximum transfer length: 4294967295 blocks
        Optimal transfer length: 4294967295 blocks
        Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
        Maximum unmap LBA count: 8388607
        Maximum unmap block descriptor count: 1
        Optimal unmap granularity: 16383
        Unmap granularity alignment valid: 0
        Unmap granularity alignment: 0
        Maximum write same length: 0xffffffff blocks
        Maximum atomic transfer length: 0
        Atomic alignment: 0
        Atomic transfer length granularity: 0
      
      and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
      have seen in traces where it will sometimes work, but other times it
      looks like it fails and it looks like it returns failures if we send
      multiple large IOs sometimes. Also it looks like it can return 2 different
      errors. It will sometimes send iscsi reject errors indicating out of
      resources or it will send invalid cdb illegal requests check conditions.
      And then when it sends iscsi rejects it does not seem to handle retries
      when there are command sequence holes, so I could not just add code to
      try and gracefully handle that error code.
      
      The problem is that we do not have a good contact for the company,
      so we are not able to determine under what conditions it returns
      which error and why it sometimes works.
      
      So, this patch just adds a new black list flag to set targets like this to
      the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
      caused this regression, so I also ccing stable.
      Reported-by: default avatarChristian Hesse <list@eworm.de>
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      35e9a9f9
  13. 10 Apr, 2015 1 commit
  14. 27 Mar, 2015 1 commit
  15. 04 Feb, 2015 1 commit
  16. 23 Jan, 2015 1 commit
    • Shaohua Li's avatar
      block: support different tag allocation policy · ee1b6f7a
      Shaohua Li authored
      The libata tag allocation is using a round-robin policy. Next patch will
      make libata use block generic tag allocation, so let's add a policy to
      tag allocation.
      
      Currently two policies: FIFO (default) and round-robin.
      
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      ee1b6f7a
  17. 20 Jan, 2015 1 commit
  18. 09 Jan, 2015 4 commits
  19. 15 Dec, 2014 1 commit
  20. 04 Dec, 2014 4 commits
  21. 27 Nov, 2014 1 commit
    • Christoph Hellwig's avatar
      libsas: remove task_collector mode · 79855d17
      Christoph Hellwig authored
      The task_collector mode (or "latency_injector", (C) Dan Willians) is an
      optional I/O path in libsas that queues up scsi commands instead of
      directly sending it to the hardware.  It generall increases latencies
      to in the optiomal case slightly reduce mmio traffic to the hardware.
      
      Only the obsolete aic94xx driver and the mvsas driver allowed to use
      it without recompiling the kernel, and most drivers didn't support it
      at all.
      
      Remove the giant blob of code to allow better optimizations for scsi-mq
      in the future.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      79855d17
  22. 24 Nov, 2014 6 commits
  23. 12 Nov, 2014 1 commit
    • Christoph Hellwig's avatar
      scsi: don't set tagging state from scsi_adjust_queue_depth · c8b09f6f
      Christoph Hellwig authored
      Remove the tagged argument from scsi_adjust_queue_depth, and just let it
      handle the queue depth.  For most drivers those two are fairly separate,
      given that most modern drivers don't care about the SCSI "tagged" status
      of a command at all, and many old drivers allow queuing of multiple
      untagged commands in the driver.
      
      Instead we start out with the ->simple_tags flag set before calling
      ->slave_configure, which is how all drivers actually looking at
      ->simple_tags except for one worke anyway.  The one other case looks
      broken, but I've kept the behavior as-is for now.
      
      Except for that we only change ->simple_tags from the ->change_queue_type,
      and when rejecting a tag message in a single driver, so keeping this
      churn out of scsi_adjust_queue_depth is a clear win.
      
      Now that the usage of scsi_adjust_queue_depth is more obvious we can
      also remove all the trivial instances in ->slave_alloc or ->slave_configure
      that just set it to the cmd_per_lun default.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c8b09f6f