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@xxxxxxx>
>> ---
>
>> +MODULE_PARM_DESC(scan, "sync, async, manual, or none. "
>> + "Setting to 'manual' disables automatic scanning, but
>> allows "
>> + "for manual device scan via the 'scan' sysfs attribute.");
>
> nice solution
>
>> + * @rescan: passed to LUN scanning routines; SCSI_SCAN_NONE
>> for no rescan,
>> + * SCSI_SCAN_RESCAN to rescan existing LUNs, and
>> SCSI_SCAN_MANUAL
>> + * to force scanning even if 'scan=manual' is set.
>
>> @@ -1621,6 +1627,10 @@ void scsi_scan_target(struct device
>> *parent, unsigned int channel,
>> if (strncmp(scsi_scan_type, "none", 4) == 0)
>> return;
>>
>> + if (rescan < SCSI_SCAN_MANUAL &&
>> + strncmp(scsi_scan_type, "manual", 6) == 0)
>> + return;
>> +
>
> I see that the ordering of identifiers in enum scsi_scan_mode allows
> a nice inequation here.
>
> However, it also seems that we need to touch all callers (which
> intend an unconditional manual scan) of scsi_scan_target() that used
> to call it with rescan==1 which would now be
> rescan==SCSI_SCAN_MANUAL==2 ?
>
Yes, sort of.
However, not _all_ callers need to be touched (as this would defeat
the purpose). We just need to touch those callers which will be
invoked by a _manual_ scan via
echo "X X X" > /sys/class/scsi_host/hostX/scan
Other callers should _not_ be modified, as the automatic scan should
be disabled.
> Or could we define the ordering of identifiers in enum
> scsi_scan_mode such that SCSI_SCAN_MANUAL happens to remain 1 so we
> don't have to touch many callers (probably there would still remain
> some callers we would have to touch because 1 does not mean MANUAL
> but RESCAN there)?
>
> 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);
>> }
>
> Not sure about: mpt_work_wrapper(), snic_scsi_scan_tgt().
>
See above. We only need to modify the call sites triggered from
drivers/scsi/scsi_sysfs.c:scsi_scan(); all other functions need to
remain as-is to allow the mechanism to work correctly.
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.
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.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
