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);
next 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