Skip to content

K
Kernel

openeuler / Kernel
接近 3 年 前同步成功

通知 11
Star 0
Fork 0
K
Kernel
You need to sign in or sign up before continuing.
切换分支/标签
  1. 03 12月, 2015 1 次提交
  3. 01 12月, 2015 1 次提交
  5. 26 11月, 2015 1 次提交
  7. 10 11月, 2015 1 次提交
  9. 29 8月, 2015 5 次提交
  11. 26 8月, 2015 1 次提交
  13. 03 8月, 2015 1 次提交
  15. 31 7月, 2015 1 次提交
    • C
      iSCSI: let session recovery_tmo sysfs writes persist across recovery · 9c8108a4
      由 Chris Leech 提交于 
      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: NChris Leech <cleech@redhat.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      9c8108a4
  17. 24 7月, 2015 2 次提交
  19. 15 7月, 2015 1 次提交
  21. 01 6月, 2015 2 次提交
  23. 19 5月, 2015 1 次提交
  25. 28 4月, 2015 1 次提交
    • M
      SCSI: add 1024 max sectors black list flag · 35e9a9f9
      由 Mike Christie 提交于 
      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: NChristian Hesse <list@eworm.de>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Cc: stable@vger.kernel.org
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      35e9a9f9
  27. 10 4月, 2015 1 次提交
  29. 27 3月, 2015 1 次提交
  31. 05 2月, 2015 1 次提交
  33. 24 1月, 2015 1 次提交
    • S
      block: support different tag allocation policy · ee1b6f7a
      由 Shaohua Li 提交于 
      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: NShaohua Li <shli@fb.com>
Signed-off-by: NJens Axboe <axboe@fb.com>
      ee1b6f7a
  35. 21 1月, 2015 1 次提交
  37. 09 1月, 2015 4 次提交
  39. 15 12月, 2014 1 次提交
  41. 04 12月, 2014 4 次提交
  43. 27 11月, 2014 1 次提交
    • C
      libsas: remove task_collector mode · 79855d17
      由 Christoph Hellwig 提交于 
      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: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.de>
Acked-by: NDan Williams <dan.j.williams@intel.com>
      79855d17
  45. 25 11月, 2014 4 次提交
  47. 24 11月, 2014 2 次提交