lsluns: clarify discovery use case, relation to NPIV and to zfcp auto LUN scan

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This commit is contained in:
Steffen Maier
2017-03-14 14:17:29 +01:00
committed by Michael Holzheu
parent e748fff347
commit 0daa7ba0b5
2 changed files with 21 additions and 0 deletions

View File

@@ -174,6 +174,9 @@ $PROGRAM_NAME [-c <busid>] ... [-p <wwpn>] ... [-h] [-v]
List LUNs discovered in the Fibre Channel (FC) Storage Area Network (SAN).
This causes extra SAN traffic for each target port WWPN.
Discovering LUNs only makes sense for NPIV-enabled FCP devices
without zfcp automatic LUN scan. zfcp automatic LUN scan is available
as of kernel version 2.6.37, if not disabled with zfcp.allow_lun_scan=0.
$PROGRAM_NAME -a [-c <busid>] ... [-p <wwpn>] ... [-h] [-v]

View File

@@ -46,6 +46,24 @@ encryption, use other tools such as
or
.BR "lsscsi \-tv" .
.SS Details on lsluns without -a option
.TP
Prerequisite
Discovering LUNs only makes sense for NPIV-enabled FCP devices
without zfcp automatic LUN scan. zfcp automatic LUN scan is available
as of kernel version 2.6.37, if not disabled with zfcp.allow_lun_scan=0.
With available and enabled zfcp automatic LUN scan,
the kernel already performs LUN discovery.
.TP
Temporary LUN Attachment
If not attached already, lsluns temporarily attaches LUN 0
(or if this fails the WLUN 0xc101000000000000) during runtime.
Do not terminate lsluns with a signal. Signals interfere
with the removal of temporarily attached LUNs.
.SH OPTIONS
.TP
.BR \-a ", " \-\-active