The purpose of this InfiniBand SRP initiator patch series is as follows:
- Make the SRP initiator driver better suited for use in a H.A. setup.
Add fast_io_fail_tmo and dev_loss_tmo parameters. These can be used
either to speed up failover or to avoid device removal when e.g. using
On 01.07.2013 16:38, James Bottomley wrote:
mv_sas is a libsas based driver. libsas doesn't have any support for
SATA PMPs. When it was added they were left as a todo item but then in
the field everyone deployed enterprise type SATA devices in SAS expander
chassis, so PMP support just got
Keep the rport data structure around after srp_remove_host() has
finished until cleanup of the IB transport layer has finished
completely. This is necessary because later patches use the rport
pointer inside the queuecommand callback. Without this patch
accessing the rport from inside a
Add the necessary functions in the SRP transport module to allow
an SRP initiator driver to implement transport layer error handling
similar to the functionality already provided by the FC transport
layer. This includes:
- Support for implementing fast_io_fail_tmo, the time that should
elapse
On 03/07/2013 15:41, Bart Van Assche wrote:
[...]
Bart,
The individual patches in this series are as follows:
0001-IB-srp-Fix-remove_one-crash-due-to-resource-exhausti.patch
0002-IB-srp-Fix-race-between-srp_queuecommand-and-srp_cla.patch
On 07/03/13 15:38, Or Gerlitz wrote:
Some of these patches were already picked by Roland (SB), I would
suggest that you post V4 and drop the ones which were accepted.
One of the patches that is already in Roland's tree and that was in v1
of this series has been split into two patches in v2
On 07/03/2013 11:00 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 10:56 -0400, Ric Wheeler wrote:
On 07/03/2013 10:38 AM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 10:34:04)
As I was out walking Skeeter this morning, I was thinking a bit about the new
T10 atomic write proposal
On Wed, 2013-07-03 at 14:52 +0200, Hajo Möller wrote:
On 01.07.2013 16:38, James Bottomley wrote:
mv_sas is a libsas based driver. libsas doesn't have any support for
SATA PMPs. When it was added they were left as a todo item but then in
the field everyone deployed enterprise type SATA
On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
On 07/03/2013 11:00 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 10:56 -0400, Ric Wheeler wrote:
On 07/03/2013 10:38 AM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 10:34:04)
As I was out walking Skeeter this morning, I was
On Wed, 2013-07-03 at 14:54 +0200, Bart Van Assche wrote:
+int srp_tmo_valid(int fast_io_fail_tmo, int dev_loss_tmo)
+{
+ return (fast_io_fail_tmo 0 || dev_loss_tmo 0 ||
+ fast_io_fail_tmo dev_loss_tmo)
+ fast_io_fail_tmo = SCSI_DEVICE_BLOCK_MAX_TIMEOUT
+
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
Why not have the atomic write actually imply that it is atomic and durable
for
just that command?
I don't understand why you think
On 07/03/2013 11:37 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
Why not have the atomic write actually imply that it is atomic and durable for
just that
On 7/2/2013 9:21 PM, Santosh Y wrote:
On Fri, Jun 28, 2013 at 5:02 PM, Sujit Reddy Thumma
sthu...@codeaurora.org wrote:
On 6/27/2013 4:49 PM, Santosh Y wrote:
+ spin_lock_irqsave(host-host_lock, flags);
task_req_descp = hba-utmrdl_base_addr;
task_req_descp +=
Quoting Ric Wheeler (2013-07-03 11:42:38)
On 07/03/2013 11:37 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
Why not have the atomic write actually imply
On Wed, Jul 3, 2013 at 9:22 PM, Sujit Reddy Thumma
sthu...@codeaurora.org wrote:
On 7/2/2013 9:21 PM, Santosh Y wrote:
On Fri, Jun 28, 2013 at 5:02 PM, Sujit Reddy Thumma
sthu...@codeaurora.org wrote:
On 6/27/2013 4:49 PM, Santosh Y wrote:
+ spin_lock_irqsave(host-host_lock, flags);
On 7/3/2013 9:53 PM, Santosh Y wrote:
On Wed, Jul 3, 2013 at 9:22 PM, Sujit Reddy Thumma
sthu...@codeaurora.org wrote:
On 7/2/2013 9:21 PM, Santosh Y wrote:
On Fri, Jun 28, 2013 at 5:02 PM, Sujit Reddy Thumma
sthu...@codeaurora.org wrote:
On 6/27/2013 4:49 PM, Santosh Y wrote:
+
On 7/3/2013 11:19 AM, Santosh Y wrote:
+
+/**
+ * ufshcd_eh_device_reset_handler - device reset handler registered to
+ *scsi layer.
+ * @cmd - SCSI command pointer
+ *
+ * Returns SUCCESS/FAILED
+ */
+static int ufshcd_eh_device_reset_handler(struct scsi_cmnd
+
+/**
+ * ufshcd_fatal_err_handler - handle fatal errors
+ * @work: pointer to work structure
*/
static void ufshcd_fatal_err_handler(struct work_struct *work)
{
struct ufs_hba *hba;
+ unsigned long flags;
+ u32 err_xfer = 0;
+ u32 err_tm = 0;
+ int
On 07/03/13 19:27, David Dillow wrote:
On Wed, 2013-07-03 at 18:00 +0200, Bart Van Assche wrote:
The combination of dev_loss_tmo off and reconnect_delay 0 worked fine
in my tests. An I/O failure was detected shortly after the cable to the
target was pulled. I/O resumed shortly after the cable
On 07/03/2013 11:54 AM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 11:42:38)
On 07/03/2013 11:37 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
Why
Quoting Ric Wheeler (2013-07-03 14:31:59)
On 07/03/2013 11:54 AM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 11:42:38)
On 07/03/2013 11:37 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22 AM, James Bottomley wrote:
On Wed,
On Wed, 2013-07-03 at 20:24 +0200, Bart Van Assche wrote:
On 07/03/13 19:27, David Dillow wrote:
On Wed, 2013-07-03 at 18:00 +0200, Bart Van Assche wrote:
The combination of dev_loss_tmo off and reconnect_delay 0 worked fine
in my tests. An I/O failure was detected shortly after the cable
On 07/03/2013 02:54 PM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 14:31:59)
On 07/03/2013 11:54 AM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 11:42:38)
On 07/03/2013 11:37 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22
David Dillow wrote:
On Wed, 2013-07-03 at 20:24 +0200, Bart Van Assche wrote:
On 07/03/13 19:27, David Dillow wrote:
On Wed, 2013-07-03 at 18:00 +0200, Bart Van Assche wrote:
The combination of dev_loss_tmo off and reconnect_delay 0 worked fine
in my tests. An I/O failure was
On Thu, Jun 20, 2013 at 04:17:13PM -0400, Matthew Wilcox wrote:
A paper at FAST2012
(http://static.usenix.org/events/fast12/tech/full_papers/Yang.pdf) pointed
out the performance overhead of taking interrupts for low-latency block
I/Os. The solution the author investigated was to spin
Ric Wheeler, on 07/03/2013 11:31 AM wrote:
Journals are normally big (128MB or so?) - I don't think that this is
unique to xfs.
We're mixing a bunch of concepts here. The filesystems have a lot of
different requirements, and atomics are just one small part.
Creating a new file often uses
26 matches
Mail list logo
