From: Steffen Maier <maier@linux.vnet.ibm.com>
To: Hannes Reinecke <hare@suse.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
James Bottomley <james.bottomley@hansenpartnership.com>,
linux-scsi@vger.kernel.org
Subject: Re: [PATCHv2] scsi: disable automatic target scan
Date: Tue, 15 Mar 2016 12:48:52 +0100 [thread overview]
Message-ID: <56E7F6A4.7090201@linux.vnet.ibm.com> (raw)
In-Reply-To: <56E7F1C3.7030801@suse.de>
On 03/15/2016 12:28 PM, Hannes Reinecke wrote:
> On 03/15/2016 12:03 PM, Steffen Maier wrote:
>> On 03/15/2016 08:19 AM, Hannes Reinecke wrote:
>>> On larger installations it is useful to disable automatic LUN
>>> scanning, and only add the required LUNs via udev rules.
>>> This can speed up bootup dramatically.
>>>
>>> This patch introduces a new scan module parameter value 'manual',
>>> which works like 'none', but can be overriden by setting the 'rescan'
>>> value from scsi_scan_target to 'SCSI_SCAN_MANUAL'.
>>> And it updates all relevant callers to set the 'rescan' value
>>> to 'SCSI_SCAN_MANUAL' if invoked via the 'scan' option in sysfs.
>>>
>>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>> In particular, the following might be necessary in order not to
>> break zfcp manual LUN addition (as long as zfcp still has its own
>> unit_add sysfs interface; completely replacing it with the solution
>> here is not easy because it breaks the zfcp sysfs user interface):
>>
>>> void zfcp_unit_scsi_scan(struct zfcp_unit *unit)
>>> {
>>> struct fc_rport *rport = unit->port->rport;
>>> u64 lun;
>>>
>>> lun = scsilun_to_int((struct scsi_lun *) &unit->fcp_lun);
>>>
>>> if (rport && rport->port_state == FC_PORTSTATE_ONLINE)
>>> - scsi_scan_target(&rport->dev, 0, rport->scsi_target_id,
>>> lun, 1);
>>> + scsi_scan_target(&rport->dev, 0, rport->scsi_target_id,
>>> lun,
>>> + SCSI_SCAN_MANUAL);
>>> }
> As for zfcp: it also relies on the 'user_scan' callback from
> scsi_transport_fc, so it will fall under the same rules as any
> 'normal' FC HBA.
I'm not sure, since zfcp needs to continue to support HBA hardware
virtualization without NPIV.
The zfcp unit_add sysfs interface is kind of a peer of your common code
scsi scan interface interface. I think, for zfcp users, a unit_add needs
to be sufficient. It would be strange to additionally have them also
write the same LUN into the Scsi_Host's scan sysfs attribute, i.e.
having to double configure things.
> But I do think we can tie the 'scan' module parameter with the
> 'allow_lun_scan' parameter from zfcp; both are now doing essentially
> the same. Eg the 'allow_lun_scan' parameter could take it's default
> value from the 'scan' parameter.
> In the long run we might want to check if and how the global 'scan'
> parameter can be moved down to a host parameter, which then would
> eliminate the need for a zfcp-specific parameter.
I need to think about this.
--
Mit freundlichen Grüßen / Kind regards
Steffen Maier
Linux on z Systems Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
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
next prev parent reply other threads:[~2016-03-15 11:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 7:19 [PATCHv2] scsi: disable automatic target scan Hannes Reinecke
2016-03-15 8:31 ` Johannes Thumshirn
2016-03-15 11:03 ` Steffen Maier
2016-03-15 11:28 ` Hannes Reinecke
2016-03-15 11:48 ` Steffen Maier [this message]
2016-03-15 11:54 ` Hannes Reinecke
2016-03-15 13:36 ` Christoph Hellwig
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=56E7F6A4.7090201@linux.vnet.ibm.com \
--to=maier@linux.vnet.ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=james.bottomley@hansenpartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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;
as well as URLs for NNTP newsgroup(s).