public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Reed <mdr@sgi.com>
To: linux-scsi <linux-scsi@vger.kernel.org>
Cc: James.Smart@Emulex.Com, Jim Nead <jnead@sgi.com>,
	Jeremy Higdon <jeremy@sgi.com>, Michael Reed <mdr@sgi.com>,
	Gary Hagensen <gwh@sgi.com>
Subject: [PATCH] make fc transport removal of target configurable
Date: Mon, 12 Jun 2006 18:16:42 -0500	[thread overview]
Message-ID: <448DF5DA.3070800@sgi.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

If the fc transport removes the scsi infrastructure for a
disconnected target and that target subsequently returns,
those subsystems layered upon scsi which don't understand
the implications of this disconnection / reconnection may
be unable to access the reconnected scsi target.  This patch
makes the target removal configurable.

Signed-off-by: Michael Reed <mdr@sgi.com>



[-- Attachment #2: fc_transport_optional_remove.patch --]
[-- Type: text/x-patch, Size: 2209 bytes --]

--- rc6u/drivers/scsi/scsi_transport_fc.c	2006-06-07 12:21:31.000000000 -0500
+++ rc6/drivers/scsi/scsi_transport_fc.c	2006-06-12 17:23:34.135974222 -0500
@@ -374,9 +374,29 @@
 MODULE_PARM_DESC(dev_loss_tmo,
 		 "Maximum number of seconds that the FC transport should"
 		 " insulate the loss of a remote port. Once this value is"
-		 " exceeded, the scsi target is removed. Value should be"
+		 " exceeded, the scsi target may be removed. Reference the
+		 " remove_on_dev_loss module parameter.  Value should be"
 		 " between 1 and SCSI_DEVICE_BLOCK_MAX_TIMEOUT.");
 
+/*
+ * remove_on_dev_loss: controls whether the transport will
+ *   remove a scsi target after the device loss timer expires.
+ *   Removal on disconnect is modeled after the USB subsystem
+ *   and expects subsystems layered on SCSI to be aware of
+ *   potential device loss and handle it appropriately. However,
+ *   many subsystems do not support device removal, leaving situations
+ *   where structure references may remain, causing new device
+ *   name assignments, etc., if the target returns.
+ */
+static unsigned int fc_remove_on_dev_loss = 0;
+module_param_named(remove_on_dev_loss, fc_remove_on_dev_loss,
+		   int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(remove_on_dev_loss,
+    		"Boolean.  When the device loss timer fires, this variable"
+		" controls whether the scsi infrastructure for the target"
+		" device is removed.  Values: zero means do not remove,"
+		" non-zero means remove.  Default is zero.");
+
 
 static __init int fc_transport_init(void)
 {
@@ -1446,7 +1466,8 @@
 	}
 	spin_unlock_irqrestore(shost->host_lock, flags);
 
-	scsi_remove_target(&rport->dev);
+	if (fc_remove_on_dev_loss)
+		scsi_remove_target(&rport->dev);
 }
 
 
@@ -1992,9 +2013,13 @@
 		return;
 	}
 
-	dev_printk(KERN_ERR, &rport->dev,
-		"blocked FC remote port time out: removing target and "
-		"saving binding\n");
+	if (fc_remove_on_dev_loss)
+		dev_printk(KERN_ERR, &rport->dev,
+			"blocked FC remote port time out: removing target and "
+			"saving binding\n");
+	else
+		dev_printk(KERN_ERR, &rport->dev,
+			"blocked FC remote port time out: saving binding\n");
 
 	list_move_tail(&rport->peers, &fc_host->rport_bindings);
 

             reply	other threads:[~2006-06-12 23:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-12 23:16 Michael Reed [this message]
2006-06-13  7:07 ` [PATCH] make fc transport removal of target configurable Christoph Hellwig
2006-06-13 11:06   ` James Smart
2006-06-13 15:42     ` Michael Reed
2006-06-13 17:24       ` Stefan Richter
2006-06-13 19:36         ` Michael Reed
2006-06-13 23:13           ` Stefan Richter
2006-06-13 17:33       ` Steve Byan
2006-06-13 19:35         ` Michael Reed
2006-06-13 19:49           ` Steve Byan
2006-06-13 17:59       ` James Bottomley
2006-06-13 19:37         ` Michael Reed
2006-06-13 20:02           ` James Bottomley
2006-06-13 21:44             ` Michael Reed
2006-06-14  7:21               ` Hannes Reinecke
2006-06-14 16:18                 ` Mike Christie
2006-06-14 16:31             ` Mike Christie
2006-06-15  9:04               ` Stefan Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=448DF5DA.3070800@sgi.com \
    --to=mdr@sgi.com \
    --cc=James.Smart@Emulex.Com \
    --cc=gwh@sgi.com \
    --cc=jeremy@sgi.com \
    --cc=jnead@sgi.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox