Re: [PATCHv3] scsi: disable automatic target scan
On 09:29 Fri 01 Apr , Hannes Reinecke wrote: > On 03/30/2016 09:41 PM, Benjamin Block wrote: > > Hello Hannes, > > > > I am a bit late here, but as this got pulled and Steffen didn't have > > time to give it a review, I did today. > > > > On 08:39 Thu 17 Mar , 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 > >> --- > > > > [:snip:] > > > >> > >> diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c > >> index 157d3d2..08bba7c 100644 > >> --- a/drivers/s390/scsi/zfcp_unit.c > >> +++ b/drivers/s390/scsi/zfcp_unit.c > >> @@ -26,7 +26,8 @@ void zfcp_unit_scsi_scan(struct zfcp_unit *unit) > >>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_RESCAN); > > > > I'd rather use the new SCSI_SCAN_MANUAL here. We don't want this to be > > "blocked" by an attribute set in a different (new) code-path and > > config-location. > > > > This path is used by both, zfcp-recovery and -userinterfaces (sysfs) and > > in both cases we call it with the intend that the scan is really done - > > hence the SCSI_SCAN_MANUAL to force a scan. I'd find it very weird if > > suddenly our users would have to additionally use yet an other config to > > get the old interfaces working properly. > > > Okay, no problem with that. > zfcp has its own scanning rules (cf allow_lun_scan module parameter), so > setting it to 'MANUAL' will just restore the original behaviour. > > Will you be sending a patch for it? > Yeah, sry, once I am through our backlog and I find time to test that properly. Beste Grüße / Best regards, - Benjamin Block -- Linux on z Systems Development / IBM Systems & Technology Group IBM Deutschland Research & Development GmbH Vorsitz. AufsR.: Martina Koederitz /Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
On 03/30/2016 09:41 PM, Benjamin Block wrote: > Hello Hannes, > > I am a bit late here, but as this got pulled and Steffen didn't have > time to give it a review, I did today. > > On 08:39 Thu 17 Mar , 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 >> --- > > [:snip:] > >> >> diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c >> index 157d3d2..08bba7c 100644 >> --- a/drivers/s390/scsi/zfcp_unit.c >> +++ b/drivers/s390/scsi/zfcp_unit.c >> @@ -26,7 +26,8 @@ void zfcp_unit_scsi_scan(struct zfcp_unit *unit) >> 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_RESCAN); > > I'd rather use the new SCSI_SCAN_MANUAL here. We don't want this to be > "blocked" by an attribute set in a different (new) code-path and > config-location. > > This path is used by both, zfcp-recovery and -userinterfaces (sysfs) and > in both cases we call it with the intend that the scan is really done - > hence the SCSI_SCAN_MANUAL to force a scan. I'd find it very weird if > suddenly our users would have to additionally use yet an other config to > get the old interfaces working properly. > Okay, no problem with that. zfcp has its own scanning rules (cf allow_lun_scan module parameter), so setting it to 'MANUAL' will just restore the original behaviour. Will you be sending a patch for it? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
Hello Hannes, I am a bit late here, but as this got pulled and Steffen didn't have time to give it a review, I did today. On 08:39 Thu 17 Mar , 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 > --- [:snip:] > > diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c > index 157d3d2..08bba7c 100644 > --- a/drivers/s390/scsi/zfcp_unit.c > +++ b/drivers/s390/scsi/zfcp_unit.c > @@ -26,7 +26,8 @@ void zfcp_unit_scsi_scan(struct zfcp_unit *unit) > 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_RESCAN); I'd rather use the new SCSI_SCAN_MANUAL here. We don't want this to be "blocked" by an attribute set in a different (new) code-path and config-location. This path is used by both, zfcp-recovery and -userinterfaces (sysfs) and in both cases we call it with the intend that the scan is really done - hence the SCSI_SCAN_MANUAL to force a scan. I'd find it very weird if suddenly our users would have to additionally use yet an other config to get the old interfaces working properly. Beste Grüße / Best regards, - Benjamin Block -- Linux on z Systems Development / IBM Systems & Technology Group IBM Deutschland Research & Development GmbH Vorsitz. AufsR.: Martina Koederitz /Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
> "Hannes" == Hannes Reinecke writes: Hannes> On larger installations it is useful to disable automatic LUN Hannes> scanning, and only add the required LUNs via udev rules. This Hannes> can speed up bootup dramatically. Hannes> This patch introduces a new scan module parameter value Hannes> 'manual', which works like 'none', but can be overriden by Hannes> setting the 'rescan' value from scsi_scan_target to Hannes> 'SCSI_SCAN_MANUAL'. And it updates all relevant callers to set Hannes> the 'rescan' value to 'SCSI_SCAN_MANUAL' if invoked via the Hannes> 'scan' option in sysfs. Applied to 4.7/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
sda2 [ 10.481480] sd 0:1:0:0: [sda] Attached SCSI disk [ OK ] Found device /dev/mapper/rhel-root. Starting File System Check on /dev/mapper/rhel-root... [ OK ] Started File System Check on /dev/mapper/rhel-root. .. ,, Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Laurence Oberman" To: "Hannes Reinecke" Cc: "Bart Van Assche" , "Martin K. Petersen" , "Christoph Hellwig" , "James Bottomley" , linux-scsi@vger.kernel.org Sent: Monday, March 21, 2016 4:40:57 PM Subject: Re: [PATCHv3] scsi: disable automatic target scan Hello Hannes Please share latest scripts and an example of how you are using them. I have some scripts from last November, that you posted but I am sure they have changed. If not then I will modify them as appropriate, just let me know. I have added the patches and booted the system set to async, so before I boot with scsi_mod.scan=manual want to prepare my test system. This feature may be a very useful feature we would want to include in RHEL as we struggle with large LUN boot configurations all the time. When you have time and thanks Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Hannes Reinecke" To: "Bart Van Assche" , "Martin K. Petersen" Cc: "Christoph Hellwig" , "James Bottomley" , linux-scsi@vger.kernel.org Sent: Monday, March 21, 2016 3:15:10 AM Subject: Re: [PATCHv3] scsi: disable automatic target scan On 03/21/2016 02:24 AM, Bart Van Assche wrote: > On 03/19/16 08:18, Hannes Reinecke wrote: >> On 03/18/2016 10:56 PM, Bart Van Assche wrote: >>> On 03/17/2016 12:39 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. >>> >>> Hello Hannes, >>> >>> Will setting scsi_scan_type to 'manual' allow a system to boot >>> from a >>> SCSI disk? If not, are there alternatives to this approach? Would >>> it be >>> a valid alternative to e.g. introduce a new threshold parameter such >>> that only LUN numbers below this threshold are scanned during boot? >>> >> I have a patch for dracut, which will generate udev rules for all >> devices required for mounting the root fs. >> Once the system is booted properly I've got another patch for systemd >> which switches back to 'normal' scanning (ie by writing 'sync' into >> /sys/modules/scsi_mod/parameters/scan) and rescan all scsi hosts. >> >> With that there's no need to have any arbitrary limits; only the >> necessary devices are enabled during boot. > > Hello Hannes, > > That sounds like a really interesting approach. Will this approach > also work if the SCSI host and/or LUN numbers change during a reboot? > It's independent on the SCSI host as it just looks for the rport ID (FC WWPN, SAS ID, or iSCSI target name). The LUN number, however, is fixed; the whole point of this exercise is that you want to blank out individual LUNs behind a given target. Hence you need to able to address the LUNs in the first place. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
On 03/21/2016 09:40 PM, Laurence Oberman wrote:
> Hello Hannes
>
> Please share latest scripts and an example of how you are using them.
> I have some scripts from last November, that you posted but I am sure they
> have changed.
> If not then I will modify them as appropriate, just let me know.
>
> I have added the patches and booted the system set to async, so before I boot
> with
> scsi_mod.scan=manual want to prepare my test system.
> This feature may be a very useful feature we would want to include in RHEL as
> we
> struggle with large LUN boot configurations all the time.
Oh, really? Hardly a surprise.
In fact, I'm constantly surprised that RHEL ships with systemd
enabled, apparently without any issues.
Especially in large machines.
As we found to our dismay; I spent about a year to get things
running smoothly.
Or, to be precise, running at all.
Anyway.
Attached is the original patch to dracut; please check if it's the
correct version (I've changed the 'disabled' to 'manual' for
upstream submission).
I haven't included the systemd service; that's actually quite
trivial: reset the scan mode (as it's now writeable) and call
rescan-scsi-bus.sh or equivalent.
But please add a 'Tested-by' or equivalent to the upstream patch, to
add a bit more urgency to it.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +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)
From 1d427bcf3527ba96828a4bd5231409967ff096b4 Mon Sep 17 00:00:00 2001
From: Hannes Reinecke
Date: Wed, 11 Nov 2015 12:20:33 +0100
Subject: [PATCH] 95lunmask: Add module to handle LUN masking
Using the module option 'scsi_mod.scan=disabled'
this implements LUN masking by selectively enable only those
devices required for booting.
References: bsc#954600
Signed-off-by: Hannes Reinecke
---
modules.d/95lunmask/fc_transport_scan_lun.sh | 26 ++
modules.d/95lunmask/module-setup.sh | 70 +++
modules.d/95lunmask/parse-lunmask.sh | 40 +++
modules.d/95lunmask/sas_transport_scan_lun.sh | 26 ++
4 files changed, 162 insertions(+)
create mode 100755 modules.d/95lunmask/fc_transport_scan_lun.sh
create mode 100755 modules.d/95lunmask/module-setup.sh
create mode 100755 modules.d/95lunmask/parse-lunmask.sh
create mode 100755 modules.d/95lunmask/sas_transport_scan_lun.sh
diff --git a/modules.d/95lunmask/fc_transport_scan_lun.sh b/modules.d/95lunmask/fc_transport_scan_lun.sh
new file mode 100755
index 000..d9f84a3
--- /dev/null
+++ b/modules.d/95lunmask/fc_transport_scan_lun.sh
@@ -0,0 +1,26 @@
+#!/bin/bash
+#
+# fc_transport_lun_scan
+#
+# Selectively enable individual LUNs behind an FC remote port
+#
+# ACTION=="add", SUBSYSTEM=="fc_transport", ATTR{port_name}=="wwpn", \
+#PROGRAM="fc_transport_lun_scan lun"
+#
+
+[ -z $DEVPATH ] && exit 1
+
+if [ -n "$1" ] ; then
+LUN=$1
+else
+LUN=-
+fi
+ID=${DEVPATH##*/rport-}
+HOST=${ID%%:*}
+CHANNEL=${ID%%-*}
+CHANNEL=${CHANNEL#*:}
+if [ -f /sys$DEVPATH/scsi_target_id ] ; then
+TARGET=$(cat /sys$DEVPATH/scsi_target_id)
+fi
+[ -z "$TARGET" ] && exit 1
+echo $CHANNEL $TARGET $LUN > /sys/class/scsi_host/host$HOST/scan
diff --git a/modules.d/95lunmask/module-setup.sh b/modules.d/95lunmask/module-setup.sh
new file mode 100755
index 000..c88b1c0
--- /dev/null
+++ b/modules.d/95lunmask/module-setup.sh
@@ -0,0 +1,70 @@
+#!/bin/bash
+# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
+# ex: ts=8 sw=4 sts=4 et filetype=sh
+
+# called by dracut
+cmdline() {
+get_lunmask() {
+local _dev=$1
+local _devpath=$(cd -P /sys/dev/block/$_dev ; echo $PWD)
+local _sdev _lun _rport _end_device _classdev _wwpn _sas_address
+
+[ "${_devpath#*/sd}" == "$_devpath" ] && return 1
+_sdev="${_devpath%%/block/*}"
+_lun="${_sdev##*:}"
+# Check for FibreChannel
+_rport="${_devpath##*/rport-}"
+if [ "$_rport" != "$_devpath" ] ; then
+_rport="${_rport%%/*}"
+_classdev="/sys/class/fc_remote_ports/rport-${_rport}"
+[ -d "$_classdev" ] || return 1
+_wwpn=$(cat ${_classdev}/port_name)
+echo "rd.lunmask=fc,${_wwpn},${_lun}"
+return 0
+fi
+# Check for SAS
+_end_device="${_devpath##*/end_device-}"
+if [ "$_end_device" != "$_devpath" ] ; then
+_end_device="${_end_device%%/*}"
+_classdev="/sys/class/sas_device/end_device-${_end_device}"
+[ -e "$_classdev" ] || return 1
+_sas_address=$(cat ${_classdev}/sas_address)
+echo "rd.lunmask=sas,${_sas_address},${_lun}"
+return 0
+fi
+return 1
+}
+[[ $hostonly ]] || [[ $mount_needs ]] && {
+for_each_host_dev_and_slaves_all get_lunmask
+
Re: [PATCHv3] scsi: disable automatic target scan
Hello Hannes Please share latest scripts and an example of how you are using them. I have some scripts from last November, that you posted but I am sure they have changed. If not then I will modify them as appropriate, just let me know. I have added the patches and booted the system set to async, so before I boot with scsi_mod.scan=manual want to prepare my test system. This feature may be a very useful feature we would want to include in RHEL as we struggle with large LUN boot configurations all the time. When you have time and thanks Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Hannes Reinecke" To: "Bart Van Assche" , "Martin K. Petersen" Cc: "Christoph Hellwig" , "James Bottomley" , linux-scsi@vger.kernel.org Sent: Monday, March 21, 2016 3:15:10 AM Subject: Re: [PATCHv3] scsi: disable automatic target scan On 03/21/2016 02:24 AM, Bart Van Assche wrote: > On 03/19/16 08:18, Hannes Reinecke wrote: >> On 03/18/2016 10:56 PM, Bart Van Assche wrote: >>> On 03/17/2016 12:39 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. >>> >>> Hello Hannes, >>> >>> Will setting scsi_scan_type to 'manual' allow a system to boot >>> from a >>> SCSI disk? If not, are there alternatives to this approach? Would >>> it be >>> a valid alternative to e.g. introduce a new threshold parameter such >>> that only LUN numbers below this threshold are scanned during boot? >>> >> I have a patch for dracut, which will generate udev rules for all >> devices required for mounting the root fs. >> Once the system is booted properly I've got another patch for systemd >> which switches back to 'normal' scanning (ie by writing 'sync' into >> /sys/modules/scsi_mod/parameters/scan) and rescan all scsi hosts. >> >> With that there's no need to have any arbitrary limits; only the >> necessary devices are enabled during boot. > > Hello Hannes, > > That sounds like a really interesting approach. Will this approach > also work if the SCSI host and/or LUN numbers change during a reboot? > It's independent on the SCSI host as it just looks for the rport ID (FC WWPN, SAS ID, or iSCSI target name). The LUN number, however, is fixed; the whole point of this exercise is that you want to blank out individual LUNs behind a given target. Hence you need to able to address the LUNs in the first place. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
On 03/21/2016 02:24 AM, Bart Van Assche wrote: > On 03/19/16 08:18, Hannes Reinecke wrote: >> On 03/18/2016 10:56 PM, Bart Van Assche wrote: >>> On 03/17/2016 12:39 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. >>> >>> Hello Hannes, >>> >>> Will setting scsi_scan_type to 'manual' allow a system to boot >>> from a >>> SCSI disk? If not, are there alternatives to this approach? Would >>> it be >>> a valid alternative to e.g. introduce a new threshold parameter such >>> that only LUN numbers below this threshold are scanned during boot? >>> >> I have a patch for dracut, which will generate udev rules for all >> devices required for mounting the root fs. >> Once the system is booted properly I've got another patch for systemd >> which switches back to 'normal' scanning (ie by writing 'sync' into >> /sys/modules/scsi_mod/parameters/scan) and rescan all scsi hosts. >> >> With that there's no need to have any arbitrary limits; only the >> necessary devices are enabled during boot. > > Hello Hannes, > > That sounds like a really interesting approach. Will this approach > also work if the SCSI host and/or LUN numbers change during a reboot? > It's independent on the SCSI host as it just looks for the rport ID (FC WWPN, SAS ID, or iSCSI target name). The LUN number, however, is fixed; the whole point of this exercise is that you want to blank out individual LUNs behind a given target. Hence you need to able to address the LUNs in the first place. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
On 03/19/16 08:18, Hannes Reinecke wrote: On 03/18/2016 10:56 PM, Bart Van Assche wrote: On 03/17/2016 12:39 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. Hello Hannes, Will setting scsi_scan_type to 'manual' allow a system to boot from a SCSI disk? If not, are there alternatives to this approach? Would it be a valid alternative to e.g. introduce a new threshold parameter such that only LUN numbers below this threshold are scanned during boot? I have a patch for dracut, which will generate udev rules for all devices required for mounting the root fs. Once the system is booted properly I've got another patch for systemd which switches back to 'normal' scanning (ie by writing 'sync' into /sys/modules/scsi_mod/parameters/scan) and rescan all scsi hosts. With that there's no need to have any arbitrary limits; only the necessary devices are enabled during boot. Hello Hannes, That sounds like a really interesting approach. Will this approach also work if the SCSI host and/or LUN numbers change during a reboot? Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
Hi Hannes, Please share those dracut patches because I want to test this patch series. Which kernel is the diff against for the scan patches. Thanks Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Hannes Reinecke" To: "Bart Van Assche" , "Martin K. Petersen" Cc: "Christoph Hellwig" , "James Bottomley" , linux-scsi@vger.kernel.org Sent: Saturday, March 19, 2016 11:18:09 AM Subject: Re: [PATCHv3] scsi: disable automatic target scan On 03/18/2016 10:56 PM, Bart Van Assche wrote: > On 03/17/2016 12:39 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. > > Hello Hannes, > > Will setting scsi_scan_type to 'manual' allow a system to boot from a > SCSI disk? If not, are there alternatives to this approach? Would it be > a valid alternative to e.g. introduce a new threshold parameter such > that only LUN numbers below this threshold are scanned during boot? > I have a patch for dracut, which will generate udev rules for all devices required for mounting the root fs. Once the system is booted properly I've got another patch for systemd which switches back to 'normal' scanning (ie by writing 'sync' into /sys/modules/scsi_mod/parameters/scan) and rescan all scsi hosts. With that there's no need to have any arbitrary limits; only the necessary devices are enabled during boot. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
On 03/18/2016 10:56 PM, Bart Van Assche wrote: > On 03/17/2016 12:39 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. > > Hello Hannes, > > Will setting scsi_scan_type to 'manual' allow a system to boot from a > SCSI disk? If not, are there alternatives to this approach? Would it be > a valid alternative to e.g. introduce a new threshold parameter such > that only LUN numbers below this threshold are scanned during boot? > I have a patch for dracut, which will generate udev rules for all devices required for mounting the root fs. Once the system is booted properly I've got another patch for systemd which switches back to 'normal' scanning (ie by writing 'sync' into /sys/modules/scsi_mod/parameters/scan) and rescan all scsi hosts. With that there's no need to have any arbitrary limits; only the necessary devices are enabled during boot. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] scsi: disable automatic target scan
On Thu, 2016-03-17 at 08:39 +0100, 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
> ---
> drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
> drivers/message/fusion/mptspi.c | 2 +-
> drivers/s390/scsi/zfcp_unit.c | 3 ++-
> drivers/scsi/scsi_priv.h| 2 +-
> drivers/scsi/scsi_proc.c| 3 ++-
> drivers/scsi/scsi_scan.c| 44
> +
> drivers/scsi/scsi_sysfs.c | 3 ++-
> drivers/scsi/scsi_transport_fc.c| 6 +++--
> drivers/scsi/scsi_transport_iscsi.c | 5 -
> drivers/scsi/scsi_transport_sas.c | 7 +++---
> drivers/scsi/snic/snic_disc.c | 2 +-
> include/scsi/scsi_device.h | 9 +++-
> 12 files changed, 60 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
> b/drivers/infiniband/ulp/srp/ib_srp.c
> index 03022f6..1f97381 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2851,7 +2851,7 @@ static int srp_add_target(struct srp_host *host, struct
> srp_target_port *target)
> spin_unlock(&host->target_lock);
>
> scsi_scan_target(&target->scsi_host->shost_gendev,
> - 0, target->scsi_id, SCAN_WILD_CARD, 0);
> + 0, target->scsi_id, SCAN_WILD_CARD, SCSI_SCAN_INITIAL);
>
> if (srp_connected_ch(target) < target->ch_count ||
> target->qp_in_error) {
> diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
> index 613231c..031e088 100644
> --- a/drivers/message/fusion/mptspi.c
> +++ b/drivers/message/fusion/mptspi.c
> @@ -1150,7 +1150,7 @@ static void mpt_work_wrapper(struct work_struct *work)
> }
> shost_printk(KERN_INFO, shost, MYIOC_s_FMT
> "Integrated RAID detects new device %d\n", ioc->name, disk);
> - scsi_scan_target(&ioc->sh->shost_gendev, 1, disk, 0, 1);
> + scsi_scan_target(&ioc->sh->shost_gendev, 1, disk, 0, SCSI_SCAN_RESCAN);
> }
>
>
> diff --git a/drivers/s390/scsi/zfcp_unit.c b/drivers/s390/scsi/zfcp_unit.c
> index 157d3d2..08bba7c 100644
> --- a/drivers/s390/scsi/zfcp_unit.c
> +++ b/drivers/s390/scsi/zfcp_unit.c
> @@ -26,7 +26,8 @@ void zfcp_unit_scsi_scan(struct zfcp_unit *unit)
> 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_RESCAN);
> }
>
> static void zfcp_unit_scsi_scan_work(struct work_struct *work)
> diff --git a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h
> index 27b4d0a..57a4b99 100644
> --- a/drivers/scsi/scsi_priv.h
> +++ b/drivers/scsi/scsi_priv.h
> @@ -116,7 +116,7 @@ extern void scsi_exit_procfs(void);
> extern char scsi_scan_type[];
> extern int scsi_complete_async_scans(void);
> extern int scsi_scan_host_selected(struct Scsi_Host *, unsigned int,
> -unsigned int, u64, int);
> +unsigned int, u64, enum scsi_scan_mode);
> extern void scsi_forget_host(struct Scsi_Host *);
> extern void scsi_rescan_device(struct device *);
>
> diff --git a/drivers/scsi/scsi_proc.c b/drivers/scsi/scsi_proc.c
> index 251598e..7a74b82 100644
> --- a/drivers/scsi/scsi_proc.c
> +++ b/drivers/scsi/scsi_proc.c
> @@ -251,7 +251,8 @@ static int scsi_add_single_device(uint host, uint
> channel, uint id, uint lun)
> if (shost->transportt->user_scan)
> error = shost->transportt->user_scan(shost, channel, id, lun);
> else
> - error = scsi_scan_host_selected(shost, channel, id, lun, 1);
> + error = scsi_scan_host_selected(shost, channel, id, lun,
> + SCSI_SCAN_MANUAL);
> scsi_host_put(shost);
> return error;
> }
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 97074c9..6c8ad36 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -96,10 +96,13 @@ MODULE_PARM_DESC(max_luns,
> #define SCSI_SCAN_TYPE_DEFAULT "sync"
> #endif
>
> -char scsi_scan_type[6] = SCSI_SCAN_TYPE_DEFAULT;
> +char scsi_scan_type[7] = SCSI_SCAN_TYPE_DEFAULT;
>
> -module_param_string(scan, scsi_scan_type, sizeof(scsi_scan_type), S_IRUGO);
> -MODULE_PARM_DESC(scan, "sync, async or none");
> +module_param_string(
Re: [PATCHv3] scsi: disable automatic target scan
On 03/17/2016 12:39 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. Hello Hannes, Will setting scsi_scan_type to 'manual' allow a system to boot from a SCSI disk? If not, are there alternatives to this approach? Would it be a valid alternative to e.g. introduce a new threshold parameter such that only LUN numbers below this threshold are scanned during boot? Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
