public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Smart <James.Smart@Emulex.Com>
To: Christof Schmitt <christof.schmitt@de.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [RFC] FC transport: Disable LUN scanning from low level driver
Date: Mon, 20 Aug 2007 21:07:23 -0400	[thread overview]
Message-ID: <46CA3ACB.7070708@emulex.com> (raw)
In-Reply-To: <20070820112121.GA1487@schmichrtp.de.ibm.com>

I'd prefer a flag/bit in the fc template to indicate no scanning by the
transport. Thus, it's up to the driver to call __scsi_add_device, or
perform the appropriate scans...

Note: this doesn't stop the problem in absolute. as long as there's scan
interfaces via sysfs, any tool/admin could request a scan and hit your
issues. To truly solve it, you need, within the LLDD, to munge what the
midlayer sees for LUN lists.

-- james s


Christof Schmitt wrote:
> The FC transport class calls scsi_scan_target with the SCAN_WILD_CARD
> flag to automatically scan for logical units. zfcp, on the other hand,
> only uses the units that are configured via the zfcp sysfs interface.
> The main reason for this, is that the adapter behind zfcp supports
> adapter sharing without NPIV: The adapter is logged into the SAN once,
> and each unit can be used by one Linux system. If one Linux would grab
> all LUNs, no other one can use them.
> 
> If a unit has the LUN 0, then the SCSI midlayer issue a REPORT LUNS,
> checks the found LUN against the max_lun of the hostadapter. zfcp sets
> this to 1 to only use its own managed units. If there is a LUN 0 that
> is used by zfcp, then the SCSI midlayer produces lots of messages like
> "scsi: host 0 channel 0 id 1 lun2 has a LUN larger than allowed by the
> host adapter" to indicate the mismatch between the actual LUN and the
> max_lun setting. These messages only confuse a user in the case of
> zfcp, since there is no error.
> 
> To fix this problem, the LLD (zfcp) has to be able to prevent the
> automatic scanning from the FC transport class. Attached is a patch
> that adds a parameter to fc_remote_port_add(), another approach would
> be an additional flag in the FC transport template.
> 
> What do others think? If there is an agreement, i will followup with a
> new patch.
> 
> This can go away, as soon as zfcp does not have to support the
> non-NPIV adapter sharing anymore, but this won't happen in the
> foreseeable future.
> 
> Christof Schmitt
> 
> --- linux-2.6.orig/drivers/s390/scsi/zfcp_erp.c	2007-08-14 17:00:07.000000000 +0200
> +++ linux-2.6/drivers/s390/scsi/zfcp_erp.c	2007-08-20 12:54:03.000000000 +0200
> @@ -3175,7 +3175,7 @@ zfcp_erp_action_cleanup(int action, stru
>  			ids.port_id = port->d_id;
>  			ids.roles = FC_RPORT_ROLE_FCP_TARGET;
>  			port->rport =
> -				fc_remote_port_add(adapter->scsi_host, 0, &ids);
> +				fc_remote_port_add(adapter->scsi_host, 0, &ids, 0);
>  			if (!port->rport)
>  				ZFCP_LOG_NORMAL("failed registration of rport"
>  						"(adapter %s, wwpn=0x%016Lx)\n",
> --- linux-2.6.orig/drivers/scsi/scsi_transport_fc.c	2007-08-14 17:00:07.000000000 +0200
> +++ linux-2.6/drivers/scsi/scsi_transport_fc.c	2007-08-20 12:56:15.000000000 +0200
> @@ -2360,7 +2360,7 @@ fc_rport_final_delete(struct work_struct
>   **/
>  static struct fc_rport *
>  fc_rport_create(struct Scsi_Host *shost, int channel,
> -	struct fc_rport_identifiers  *ids)
> +	struct fc_rport_identifiers  *ids, int scan_target)
>  {
>  	struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
>  	struct fc_internal *fci = to_fc_internal(shost->transportt);
> @@ -2424,6 +2424,9 @@ fc_rport_create(struct Scsi_Host *shost,
>  	transport_add_device(dev);
>  	transport_configure_device(dev);
>  
> +	if (scan_target)
> +		rport->flags |= FC_RPORT_SCAN_TARGET;
> +
>  	if (rport->roles & FC_PORT_ROLE_FCP_TARGET) {
>  		/* initiate a scan of the target */
>  		rport->flags |= FC_RPORT_SCAN_PENDING;
> @@ -2484,7 +2487,7 @@ delete_rport:
>   **/
>  struct fc_rport *
>  fc_remote_port_add(struct Scsi_Host *shost, int channel,
> -	struct fc_rport_identifiers  *ids)
> +	struct fc_rport_identifiers  *ids, int scan_target)
>  {
>  	struct fc_internal *fci = to_fc_internal(shost->transportt);
>  	struct fc_host_attrs *fc_host = shost_to_fc_host(shost);
> @@ -2574,6 +2577,10 @@ fc_remote_port_add(struct Scsi_Host *sho
>  				spin_lock_irqsave(shost->host_lock, flags);
>  
>  				rport->flags &= ~FC_RPORT_DEVLOSS_PENDING;
> +				if (scan_target)
> +					rport->flags |= FC_RPORT_SCAN_TARGET;
> +				else
> +					rport->flags &= ~FC_RPORT_SCAN_TARGET;
>  
>  				/* if target, initiate a scan */
>  				if (rport->scsi_target_id != -1) {
> @@ -2657,7 +2664,7 @@ fc_remote_port_add(struct Scsi_Host *sho
>  	spin_unlock_irqrestore(shost->host_lock, flags);
>  
>  	/* No consistent binding found - create new remote port entry */
> -	rport = fc_rport_create(shost, channel, ids);
> +	rport = fc_rport_create(shost, channel, ids, scan_target);
>  
>  	return rport;
>  }
> @@ -2991,7 +2998,8 @@ fc_scsi_scan_rport(struct work_struct *w
>  	unsigned long flags;
>  
>  	if ((rport->port_state == FC_PORTSTATE_ONLINE) &&
> -	    (rport->roles & FC_PORT_ROLE_FCP_TARGET)) {
> +	    (rport->roles & FC_PORT_ROLE_FCP_TARGET) &&
> +	    (rport->flags & FC_RPORT_SCAN_TARGET)) {
>  		scsi_scan_target(&rport->dev, rport->channel,
>  			rport->scsi_target_id, SCAN_WILD_CARD, 1);
>  	}
> --- linux-2.6.orig/include/scsi/scsi_transport_fc.h	2007-08-14 17:00:09.000000000 +0200
> +++ linux-2.6/include/scsi/scsi_transport_fc.h	2007-08-20 12:54:03.000000000 +0200
> @@ -338,6 +338,7 @@ struct fc_rport {	/* aka fc_starget_attr
>  /* bit field values for struct fc_rport "flags" field: */
>  #define FC_RPORT_DEVLOSS_PENDING	0x01
>  #define FC_RPORT_SCAN_PENDING		0x02
> +#define FC_RPORT_SCAN_TARGET		0x04
>  
>  #define	dev_to_rport(d)				\
>  	container_of(d, struct fc_rport, dev)
> @@ -713,7 +714,8 @@ struct scsi_transport_template *fc_attac
>  void fc_release_transport(struct scsi_transport_template *);
>  void fc_remove_host(struct Scsi_Host *);
>  struct fc_rport *fc_remote_port_add(struct Scsi_Host *shost,
> -			int channel, struct fc_rport_identifiers  *ids);
> +			int channel, struct fc_rport_identifiers  *ids,
> +			int scan_target);
>  void fc_remote_port_delete(struct fc_rport  *rport);
>  void fc_remote_port_rolechg(struct fc_rport  *rport, u32 roles);
>  int scsi_is_fc_rport(const struct device *);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2007-08-21  1:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-20 11:21 [RFC] FC transport: Disable LUN scanning from low level driver Christof Schmitt
2007-08-21  1:07 ` James Smart [this message]
2007-08-21 12:36   ` Christof Schmitt
2007-08-21 13:03     ` James Smart
2007-08-21 15:31       ` Christof Schmitt

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=46CA3ACB.7070708@emulex.com \
    --to=james.smart@emulex.com \
    --cc=christof.schmitt@de.ibm.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