EOF of iSCSI Target Daemon [PSARC/2010/006 FastTrack timeout 01/13/2010]
This case has timed out with a +1 and has been marked closed approved. - John
EOF of iSCSI Target Daemon [PSARC/2010/006 FastTrack timeout 01/13/2010]
I am sponsoring this fasttrack for Jim Dunham. Timeout is set for 01/13/2010. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF of iSCSI Target Daemon 1.2. Name of Document Author/Supplier: Author: James Dunham 1.3 Date of This Document: 06 January, 2010 2. Project Summary 2.1. Project Description This proposal is to remove support for the iSCSI Target Daemon from Solaris Next and OpenSolaris. This fast-track is for advance warning that within Solaris Next and OpenSolaris, the iSCSI Target Daemon, the CLI iscsitadm, the man page iscsitadm(1M), and ZFS's support for 'shareiscsi' support for ZVOLs will be removed. The PSARC cases being deprecated as a result of accepting this proposal are as follows: - PSARC/2007/153 iSCSI target provider - PSARC/2007/414 SCF changes for iSCSI Target - PSARC/2006/622 iSCSI/ZFS Integration - PSARC/2009/168 iSCSI Target PGR directory for ZVOLs The iSCSI Target in COMSTAR will replace all of the aforementioned functionality in Solaris Next and OpenSolaris, with the exception of ZFS's support for 'shareiscsi'. COMSTAR consists of the following PSARC cases: - PSARC/2007/523 COMSTAR: Common Multiprotocol SCSI Target - PSARC/2008/235 SCSI Block Disk Provider for COMSTAR - PSARC/2008/587 iSCSI Port Provider for COMSTAR - PSARC/2009/111 COMSTAR Infiniband SRP Target - PSARC/2008/395 iSER: iSCSI Extensions for RDMA - PSARC/2008/310 FCoE (Fibre Channel over Ethernet) Target 2.2. Risks and Assumptions The architectural design of the iSCSI Target Daemon and ZFS's shareiscsi support, being PSARC/2006/662, is not extensible in its present form, as the underlying implementation is based on a tight association many iSCSI Targets, supporting only a LUN 0, for each shareiscsi enabled ZVOL. COMSTAR's is a multi-protocol SCSI Target implementation that provides support for different types of SCSI Targets, not just iSCSI, supporting LUN numbers up to 16K. ZVOLs are used as backing store devices for SCSI Initiators using one or more or COMSTAR's support protocols. Although the iSCSI Target in COMSTAR is a functional replacement for the iSCSI Target Daemon, there is no means to provide an automated upgrade from one form of iSCSI Target to the other. The iSCSI Target Daemon, and ZFS shareiscsi support, presented a model of many iSCSI Target IDs, with one iSCSI LUNs per target. The iSCSI Target in COMSTAR presents a model of limited iSCSI Target IDs, currently 32, and many iSCSI LUNs per target, up to 16384. A many targets and one LU model, does not map into a few targets, with many LU model. As part of the Solaris Next documentation, a step by step description of how to upgrade existing iSCSI Target Daemon LUs to iSCSI Target LUs in COMSTAR will be provided. 3. Business Summary 3.1. Problem Area Providing and supporting two different implementations of an iSCSI Target service is confusing to both system administrators and end users of Solaris, and also creates an unwanted support burden on Sun, having to support two totally different implementations of an iSCSI Target. The iSCSI Target in COMSTAR, and its use in the Sun Storage 7000 Unified Storage Server, the iSCSI Target in COMSTAR has proven itself as an enterprise class iSCSI Target implementation, in features, functionality, performance and overall stability. This is not the general consensus with the iSCSI Target Daemon, known to be an inferior iSCSI Target implementation. 3.2. Market/Requester 3.3. Business Justification The iSCSI Target in COMSTAR is built on an enterprise class, Common Multiprotocol SCSI Target, that in addition to providing support for iSCSI Targets, it also provides support for iSER, SRP, FC and FCoE SCSI Targets. COMSTAR provides proven block based SCSI Targets support for Solaris Next, OpenSolaris and the Sun Storage 7000 Unified Storage Systems. 3.4. Competitive Analysis Sun has a unique position over other storage vendors and operating systems, in that the iSCSI Target in COMSTAR is Open Source, based on Open Standards, for ubiquitous access to Open Storage. 3.5. Opportunity Window/Exposure Solaris Next, OpenSolaris, Sun Storage 7000 Unified Storage Systems 3.6. How will you know when you are done? Removal of the iSCSI Target in Solaris Next, OpenSolaris, and an
COMSTAR SRPT Port Provider Management [PSARC/2009/634 FastTrack timeout 11/25/2009]
This case was approved at PSARC today. - John
COMSTAR SRPT Port Provider Management [PSARC/2009/634 FastTrack timeout 11/25/2009]
This case timed out on 11/25 without any +1. Can a PSARC member please review it? - John
COMSTAR SRPT Port Provider Management [PSARC/2009/634 FastTrack timeout 11/25/2009]
I am sponsoring this fasttrack for Sue Gleeson. Requested binding is minor. Timeout is set for 11/25/2009. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: COMSTAR SRPT Port Provider Management 1.2. Name of Document Author/Supplier: Author: Susan Gleeson 1.3 Date of This Document: 18 November, 2009 4. Technical Description The COMSTAR Infiniband SRP Target project (PSARC/2009/111 [1]) introduced the SRP protocol port provider to Solaris. When the SRP port provider SMF service is enabled, COMSTAR targets are created for every Infiniband HCA discovered on the system. It has become clear that a finer level of control is required, and this set of interfaces will allow for changing the default behavior when the service is activated as well as enabling and disabling SRP services on a per-HCA basis. This case introduces a new library, libsrpt and a new CLI, srptadm as described below. 4.1 Interfaces Minor binding. -+---+- InterfaceClassification Comments -+---+- libsrpt | Committed | srptadm | Committed 4.2 srpt_SetDefaultState/srpt_GetDefaultState NAME srpt_SetDefaultState, srpt_GetDefaultState - set and retrieve the default state setting for the SRP Target service. SYNOPSIS cc [ flag... ] file... -lsrpt [ library... ] #include libsrpt.h int srpt_SetDefaultState(boolean_t enabled); int srpt_GetDefaultState(boolean_t *enabled); PARAMETERS enabledboolean value indicating whether COMSTAR SRP targets should be created. DESCRIPTION The srpt_SetDefaultState() function sets the default behavior of the SRP Target service. If enabled is B_TRUE, SRP targets will be created for all discovered HCAs that have not been specifically disabled. If enabled is B_FALSE, targets will not be created unless the HCA has been specifically enabled. See also srpt_SetTargetState() for enabling or disabling specific HCAs. If the default state is changed when the SRP service is online, the state of existing targets is not changed until the service is restarted. The srpt_GetDefaultState() function returns the current value for enabled. RETURN VALUES ENOMEM Could not allocate resources EINVAL Invalid parameter ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| MT-Safe | |_|_| SEE ALSO srpt_SetTargetState(3SRPT), libsrpt(3LIB) 4.3 srpt_SetTargetState/srpt_GetTargetState NAME srpt_SetTargetState, srpt_GetTargetState, srpt_ResetTarget - set and retrieve SRP Target state for a specific HCA. SYNOPSIS cc [ flag... ] file... -lsrpt [ library... ] #include libsrpt.h int srpt_SetTargetState(char *hca_guid, boolean_t enabled); int srpt_GetTargetState(char *hca_guid, boolean_t *enabled); int srpt_ResetTarget(char *hca_guid); PARAMETERS hc_guid HCA GUID. Must be in one of the following forms: 3BA000100CD18 - base hex form 0003BA000100CD18- base hex form with leading zeroes hca:3BA000100CD18 - form from cfgadm eui.0003BA000100CD18 - EUI form enabledboolean value indicating whether a COMSTAR SRP target should be created for this HCA. DESCRIPTION The srpt_SetTargetState() function controls whether a COMSTAR SRP target will be created for the specified HCA. If enabled is B_TRUE, an SRP target will be created for this HCA. If enabled is B_FALSE, a target will not be created. This function overrides the default setting for the SRP Target service as set by srpt_SetDefaultState(). Changing the target state takes effect immediately if the SRP target service is online. Targets set to disabled will be offlined and removed; targets set to enabled will be immediately created. The srpt_GetTargetState() function retrieves the current setting for the specified HCA. The srpt_ResetTarget() function clears HCA-specific settings. The service-wide defaults will control SRP Target creation for this HCA. RETURN VALUES ENOMEM Could not allocate resources EINVAL Invalid
Host ID for COMSTAR logical unit [PSARC/2009/547 Self Review]
I am sponsoring the following fasttrack for myself. I believe this case qualifies for self-review. If anyone disagrees, I'll convert it and set the timer. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Host ID for COMSTAR logical unit 1.2. Name of Document Author/Supplier: Author: John Forte 1.3 Date of This Document: 09 October, 2009 4. Technical Description Support for setting the host ID portion of the Globally Unique Identifier (GUID) of a COMSTAR logical unit. 4.1 Description Allows the setting of the host identifier portion of a logical unit identifier during creation of a COMSTAR logical unit. This will introduce a new logical-unit-property called host-id for the create-lu subcommand of stmfadm(1M) CLI. This case also introduces a new property STMF_LU_PROP_HOST_ID for stmfSetLuProp(3STMF) in libstmf(3LIB) (see PSARC 2007/523) library 4.2 Bug/RFE Number(s): 6861519 stmfCreateLu() should allow caller to specify host id 4.5 Interfaces Minor binding. -+---+- InterfaceClassification Comments -+---+- libstmf | Committed | PSARC 2007/523 | | PSARC 2009/251 | | stmfadm | Committed | PSARC 2007/523 output of| Not an interface| PSARC 2009/251 stmfadm| | -+---+- 4.5.1 stmfSetLuProp(3STMF)/stmfGetLuProp(3STMF) Interfaces Adding new property STMF_LU_PROP_HOST_ID for stmfSetLuProp(3STMF) interface. 4.5.2 stmfadm(1M) subcommands Adding new logical-unit-property called host-id for create-lu subcommand. 4.6 Doc Impact: 4.6.1 man page Change for stmfadm(1M) _ | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Availability| SUNWstmfu | |_|_| | Interface Stability | Committed | |_|_| information about the new logical-unit-property, host-id needs to be added along with existing logical-unit-property descriptions for -p option of the create-lu subcommand. host-id 8 hexadecimal ASCII characters representing the host ID assignment. This will be used to generate the globally unique identifier (GUID) for the logical unit. The default is the value returned by hostid(1). 4.6.2 man page change for stmfSetLuProp(3STMF)/stmfGetLuProp(3STMF) | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| Safe| |_|_| Description for the following new property needs to be added: STMF_LU_PROP_HOST_ID 8 hexadecimal ASCII characters representing the host ID assignment. This will be used to generate the globally unique identifier (GUID) for the logical unit. Default: identifer returned by hostid(1). 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Net 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
libstmf validate view interface [PSARC/2009/504 FastTrack timeout 09/28/2009]
Mark A. Carlson wrote: John Forte wrote: DESCRIPTION The stmfValidateView() function validates the logical unit number. This is done by setting view-luNbrValid to B_TRUE and setting view-luNbr to the logical unit number. A valid logical unit number is in the range of 0-16383. The stmfValidateView() function find the next available logical unit number. The is done by setting view-luNbrValid to B_FALSE. On success, the available logical unit number is returned in view-luNbr. Is the next available LUN thus reserved so that a subsequent call would return the next one? Or could multiple callers all get the same LUN and try and use it? At that point in time the logical unit number is available. Until the logical number gets used, it would be available. If there are multiple callers, yes, they could all get the same number. Any required locking is assumed to be handled by the client. - John
libstmf validate view interface [PSARC/2009/504 FastTrack timeout 09/28/2009]
Mark A. Carlson wrote: OK, as long as this is documented. The manpage/fasttrack has been updated with a clearer statement around logical unit number availability that should address this concern. The new doc has been placed in the materials directory. The stmfValidateView() function finds the next available logical unit number. This is done by setting view-luNbrValid to B_FALSE. On success, the available logical unit number is returned in view-luNbr. A logical unit number is considered to be available if it is not currently consumed by an existing view entry where the target group and host group matches the view entry passed into this function. Until the logical unit number is no longer available, any calls to this function will get the same logical unit number in view-luNbr. - John
libstmf validate view interface [PSARC/2009/504 FastTrack timeout 09/28/2009]
I am sponsoring this fasttrack for Tim Szeto. Requested binding is minor. Timeout is set for 09/28/2009. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libstmf validate view interface 1.2. Name of Document Author/Supplier: Author: Tim Szeto 1.3 Date of This Document: 21 September, 2009 4. Technical Description This case adds one new interface to libstmf (PSARC 2007/523) for validation of a logical unit number per view entry, or to find an available logical unit number per view entry. This function allows the client to better manage logical unit numbers across multiple STMF instances in a cluster environment. The new interface (stmfValidateView(3STMF)) enables the client to check if the logical unit number is in use based on the view entry parameters (target group, host group and logical unit number). This interface also enables the client to query for an available logical unit number based on the view entry. 4.1 stmfValidateView(3STMF) NAME stmfValidateView - validate/get logical unit number per view entry SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfValidateView(stmfViewEntry *view); PARAMETERS view The view entry to validate or get the logical number. DESCRIPTION The stmfValidateView() function validates the logical unit number. This is done by setting view-luNbrValid to B_TRUE and setting view-luNbr to the logical unit number. A valid logical unit number is in the range of 0-16383. The stmfValidateView() function find the next available logical unit number. The is done by setting view-luNbrValid to B_FALSE. On success, the available logical unit number is returned in view-luNbr. RETURN VALUES STMF_STATUS_SUCCESS The API call was successful STMF_ERROR_LUN_IN_USE The specified logical unit number is already in use for this logical unit. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: _ _ | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| Safe| |_|_| SEE ALSO libstmf(3LIB), attributes(5), stmfAddViewEntry(3STMF) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
COMSTAR ALUA active/standby support [PSARC/2009/465 FastTrack timeout 09/02/2009]
The timer on this case had been extended to 9/09/2009 and was approved at PSARC today. - John
COMSTAR ALUA active/standby support [PSARC/2009/465 FastTrack, timeout 09/02/2009] (John Forte)
Don Cragun wrote: 4.3 stmfGetAluaState NAME stmfGetAluaState SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfGetAluaState(boolean_t *enabled, uint8_t *node) PARAMETERS enabled set to B_TRUE or B_FALSE on success nodeset to 0 or 1 on success DESCRIPTION The stmfGetAluaState() function returns the Asymmetric Logical Unit Access State (ALUA) mode for STMF along with the node setting. RETURN VALUES The following values are returned: STMF_ERROR_INVALID_ARG Either enabled or node was NULL. STMF_STATUS_SUCCESS The API call was successful So, if I call stmfSetAluaState(B_TRUE, 0) and stmfSetAluaState(B_TRUE, 1) and then call stmfGetAluaState(state, node) what is it supposed to do? Return the last node id set, which in this case would be 1 along with a state of B_TRUE. I understand what you're doing now, but I still find disabled in this presentation mode ambiguous. I read it as Either the node (or the ALUA) is enabled, or the value of node is a null pointer. I think you've lost me. If node is NULL, it's an error. There is no ambiguity there. If the ALUA state is disabled, enabled is set to B_FALSE. Obviously, if either argument is a pointer to any correctly aligned valid address this will write over whatever is there. Is there any error reserved for a pointer to unallocated space (other than a null pointer), or is the expected result in that case memory fault - core dumped? Core dump. - John
COMSTAR ALUA active/standby support [PSARC/2009/465 FastTrack, timeout 09/02/2009] (John Forte)
Don Cragun wrote: On Wed, 26 Aug 2009 16:21:02 -0700 (PDT), John Forte wrote: ... ... ... 4.2 stmfSetAluaState NAME stmfSetAluaState SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfSetAluaState(boolean_t enabled, uint8_t node) PARAMETERS enabled B_TRUE when enabling ALUA mode B_FALSE when disabling ALUA mode I'm having trouble understanding what is going on here. Should mode in the above two lines be node? No, but the word mode could easily be replaced by state and perhaps should. nodeMust be the value 0 or 1 DESCRIPTION The stmfSetAluaState() function sets the Asymmetric Logical Unit Access State (ALUA) mode for STMF. When enabled is set to B_FALSE, node is ignored, otherwise, node must be set to 0 or 1. The node setting must be different for each node in a paired config. This should be called only after the STMF proxy door service has been initialized(See stmfInitProxyDoor(3STMF)). When the ALUA state is enabled, all STMF logical units will be registered on the peer node as standby logical units. The standby logical units can then be exported to any SCSI initiator using the existing mechanisms in STMF, stmfAddViewEntry(3STMF) or the add-view subcommand of stmfadm(1M). Note: If ALUA mode is already enabled, it is valid to call this interface again with enabled set to B_TRUE. This action would result in a re-initialization of the ALUA mode. This can be used during recovery of a failed peer node. According to the Note above, it is not an error to call stmfSetAluaState(B_TRUE, node) to reinitialize node if had it previously been enabled. Correct. RETURN VALUES The following values are returned: STMF_ERROR_INVALID_ARG Either enabled or node was incorrectly set. STMF_STATUS_SUCCESS The API call was successful According to the above two lines, stmfSetAluaState() is supposed to return STMF_ERROR_INVALID_ARG (because it was enabled) and STMF_STATUS_SUCCESS (if it successfully reinitializes node)??? I don't think it says that. STMF_ERROR_INVALID_ARG would be returned if node was neither 0 or 1. Perhaps it would be clearer if it was: RETURN VALUES The following values are returned: STMF_ERROR_INVALID_ARG Either enabled or node was incorrectly set. ? ... ... ... 4.3 stmfGetAluaState NAME stmfGetAluaState SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfGetAluaState(boolean_t *enabled, uint8_t *node) PARAMETERS enabled set to B_TRUE or B_FALSE on success nodeset to 0 or 1 on success DESCRIPTION The stmfGetAluaState() function returns the Asymmetric Logical Unit Access State (ALUA) mode for STMF along with the node setting. RETURN VALUES The following values are returned: STMF_ERROR_INVALID_ARG Either enabled or node was NULL. STMF_STATUS_SUCCESS The API call was successful So, if I call stmfSetAluaState(B_TRUE, 0) and stmfSetAluaState(B_TRUE, 1) and then call stmfGetAluaState(state, node) what is it supposed to do? Return the last node id set, which in this case would be 1 along with a state of B_TRUE. On which node is it going to report? Since both nodes have been enabled, it says that it is going to return STMF_ERROR_INVALID_ARG. STMF_ERROR_INVALID_ARG is only returned when the arguments are invalid. As long as enabled is B_TRUE or B_FALSE and node is either 0 or 1, that error would not be returned. To make this clear, node is just an identifier for the stmf instance on which the set ALUA state is executed. It isn't a target for the execution of the set ALUA state, i.e. the set is not setting the state for node 0 or node 1, it's setting the state AND setting the node identifier to 0 or 1. But if it successfully sets state and node, it also says it will return STMF_STATUS_SUCCESS??? Yes, it's just another state change. - John
COMSTAR ALUA active/standby support [PSARC/2009/465 FastTrack timeout 09/02/2009]
I am sponsoring the following fasttrack for myself. Requested binding is minor. Timeout is set for 9/02. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: COMSTAR ALUA active/standby support 1.2. Name of Document Author/Supplier: Author: John Forte 1.3 Date of This Document: 26 August, 2009 4. Technical Description COMSTAR (PSARC 2007/523 [1]) supports the SCSI standard [2] for Asymmetric Logical Unit Access (ALUA) but only supports the access state of Active/Optimized. This set of interfaces introduces support for a logical unit access state of Standby on a peer node. This support is provided via the existing libstmf(3LIB) introduced in PSARC 2007/253 and is targeted towards developers of clustered storage systems in 2 node configurations. Use of these interfaces require a peer-to-peer communication channel be established between the two participating nodes in the COMSTAR (STMF) ALUA configuration. 4.1 Interfaces Minor binding. -+---+- InterfaceClassification Comments -+---+- libstmf | Committed | PSARC 2007/523 4.2 stmfSetAluaState NAME stmfSetAluaState SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfSetAluaState(boolean_t enabled, uint8_t node) PARAMETERS enabled B_TRUE when enabling ALUA mode B_FALSE when disabling ALUA mode nodeMust be the value 0 or 1 DESCRIPTION The stmfSetAluaState() function sets the Asymmetric Logical Unit Access State (ALUA) mode for STMF. When enabled is set to B_FALSE, node is ignored, otherwise, node must be set to 0 or 1. The node setting must be different for each node in a paired config. This should be called only after the STMF proxy door service has been initialized(See stmfInitProxyDoor(3STMF)). When the ALUA state is enabled, all STMF logical units will be registered on the peer node as standby logical units. The standby logical units can then be exported to any SCSI initiator using the existing mechanisms in STMF, stmfAddViewEntry(3STMF) or the add-view subcommand of stmfadm(1M). Note: If ALUA mode is already enabled, it is valid to call this interface again with enabled set to B_TRUE. This action would result in a re-initialization of the ALUA mode. This can be used during recovery of a failed peer node. RETURN VALUES The following values are returned: STMF_ERROR_INVALID_ARG Either enabled or node was incorrectly set. STMF_STATUS_SUCCESS The API call was successful ATTRIBUTES See attributes(5) for descriptions of the following attributes: | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| Safe| |_|_| 4.3 stmfGetAluaState NAME stmfGetAluaState SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfGetAluaState(boolean_t *enabled, uint8_t *node) PARAMETERS enabled set to B_TRUE or B_FALSE on success nodeset to 0 or 1 on success DESCRIPTION The stmfGetAluaState() function returns the Asymmetric Logical Unit Access State (ALUA) mode for STMF along with the node setting. RETURN VALUES The following values are returned: STMF_ERROR_INVALID_ARG Either enabled or node was NULL. STMF_STATUS_SUCCESS The API call was successful ATTRIBUTES See attributes(5) for descriptions of the following attributes: | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| Safe| |_|_| 4.4 stmfLuStandby NAME stmfLuStandby SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfLuStandby(stmfGuid *luGuid) PARAMETERS luGuid a pointer to an stmfGuid structure containing the guid of the logical unit to set to standby DESCRIPTION The stmfLuStandby() function sets the access state of a logical unit to standby
Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009]
This case was approved at PSARC today. - John
Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009]
Garrett D'Amore wrote: In principle this looks good, and I'm almost ready to +1 it, but I have a few questions first: 1) I don't know enough about the FC protocol... will forcing target ports to reinitialize have any negative implications for the initiators? I'd like to understand the ramifications of any side effects. The initiators will get a RSCN (Remote State Change Notification) from the FC switch, which will generally cause them to rediscover for any changes to the fabric, which is generally the desired behavior from the administrator issuing this command. 2) Are any additional privileges required for this operation? What are the privileges needed to perform this action? I believe sys_devices is required. Reed? 3) Will the luxadm version of the command be Obsoleted at some point? Yes, that was the plan as noted in the PSARC 2004/291. Forcelip functionality was one of the last (perhaps the last) reason to keep luxadm around. - John
Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009]
Garrett D'Amore wrote: John Forte wrote: Garrett D'Amore wrote: In principle this looks good, and I'm almost ready to +1 it, but I have a few questions first: 1) I don't know enough about the FC protocol... will forcing target ports to reinitialize have any negative implications for the initiators? I'd like to understand the ramifications of any side effects. The initiators will get a RSCN (Remote State Change Notification) from the FC switch, which will generally cause them to rediscover for any changes to the fabric, which is generally the desired behavior from the administrator issuing this command. Does this have negative implications for any in-flight I/O? (I.e. is this command potentially destructive?) Are the implications restricted to just the target being reinitialized? (Sorry if it sounds like I'm being paranoid here, but to a certain extent a little paranoia can be helpful. :-) If its potentially destructive, then I'd like to have a warning issued to the administrator first. If it can't be destructive, then we needn't worry about it. Likely a bit disruptive but it shouldn't be destructive. Certainly the target port will re-initialize it's login with the switch. When this command was first implemented in luxadm, FC switched fabrics did not exist and it was much more disruptive in that it forced every participating port in the fibre channel arbitrated loop to renegotiate. That is no longer the case with switched fabrics in FC. I think at most we should have the documentation for the subcommand indicate the appropriate warnings to the extent that it will result in an RSCN from the switch to all zoned initiators. My preference would be to not have a warning issued to the administrator forcing a confirmation prior to executing the initialization of the link. I think FC administrators are generally savvy enough to understand the meaning of this operation and when it should be used as well as what impact it's likely to have. My opinion is anything more than a documented warning would be annoying. - John
Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009]
Torrey McMahon wrote: On 7/20/2009 2:11 PM, Garrett D'Amore wrote: John Forte wrote: Garrett D'Amore wrote: In principle this looks good, and I'm almost ready to +1 it, but I have a few questions first: 1) I don't know enough about the FC protocol... will forcing target ports to reinitialize have any negative implications for the initiators? I'd like to understand the ramifications of any side effects. The initiators will get a RSCN (Remote State Change Notification) from the FC switch, which will generally cause them to rediscover for any changes to the fabric, which is generally the desired behavior from the administrator issuing this command. Does this have negative implications for any in-flight I/O? (I.e. is this command potentially destructive?) Are the implications restricted to just the target being reinitialized? (Sorry if it sounds like I'm being paranoid here, but to a certain extent a little paranoia can be helpful. :-) If its potentially destructive, then I'd like to have a warning issued to the administrator first. If it can't be destructive, then we needn't worry about it. Does the command reset the target port completely or just it's link to the host that sends the command? When issuing it on the target port side, it causes a reset of the target port and when issuing it from the host port side, a reset of the host port is done. The same can pretty much also be accomplished by going to the switch and doing an offline/online of the desired switch port. If you had a bad guy on a host and they continually reset a target port completely you could cause issues on other hosts. Not like other commands on other protocols couldn't do the same thing but you might want to warn folks in the man page. Something like, This command will reset a storage target port impacting any host attached.. blah blah blah. Yes, I think an explanation of the likely impact of this command is reasonable. - John
Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009]
I am sponsoring this fasttrack for Reed Liu. Requested binding is minor. fcadm(1M) manpage diffs are in the materials directory. Timeout is 07/27/2009. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Fibre Channel port link reinitialize support 1.2. Name of Document Author/Supplier: Author: Reed Liu 1.3 Date of This Document: 20 July, 2009 4. Technical Description 4.1 Background When new devices are added to FC-SANs or in the case of some misbehaving devices on the SAN, the administrators sometimes wish to force the link to reinitialize. In many cases, this can resolve problems in FC-SANs. Currently luxadm(1M) can force the FC initiator links to reinitialize, but luxadm was designed and implemented to work with FC initiator ports only. 4.2 Problem The current problem is that there's no method to reinitialize the link, if it's connected with a Fibre Channel target port, which is associated with COMSTAR(PSARC/2007/523) project. 4.3 Proposed solution This project proposes to add a new subcommand to fcadm(1M), and this subcommand can force Fibre Channel links to reinitialize, both initiator and target ports. luxadm(1M) has supported forcelip to FC initiator ports, but we propose to improve fcadm(1M). Firstly, luxadm(1M) was designed and implemented to work with FC initiator ports only, it does not support FC target ports. By contrast, with PSARC/2008/187, fcinfo/fcadm supports FC target ports natively, and it also has the advantage that the implementation of forcelip for initiator and target ports will share common logic and code. Secondly, although luxadm(1M) already supports forcelip on initiator ports, it relies on hbaapi on x86 but a totally different approach on sparc. fcinfo/fcadm has the advantage of using hbaapi consistently on both x86 and sparc. 4.4 fcadm change fcadm(1M) is used to manage all kinds of Fibre Channel ports. New subcommand 'fcadm forcelip' is introduced to force the link to reinitialize. If link reinitialization is OK, there will be no any output as luxadm -e forcelip, or else there will be one error message. Following example outputs show related changes. # fcadm forcelip 21e08b909221 # ... # fcadm forcelip 210100e08b909221 Failed to reinitialize the link. # 4.5 COMSTAR fct change fcadm(1M) will interact with COMSTAR fct module through ioctl mechanism. New ioctl 'FCTIO_FORCE_LIP' is introduced, then the same command can be used regardless of different FC target ports since fct is the common layer for the fibre channel HBA drivers. 4.6 Library change The following interface will be added to libHBAAPI.so, Sun extensions of FC-HBA common library. HBA_API HBA_STATUS Sun_HBA_ForceLip(HBA_HANDLE handle, int *rval) Makes the corresponding port's link to reinitialize The existing libsun_fc.so, Sun HBA API Vendor Specific Library(VSL), will provide the forcelip support mentioned above through fct driver, which is developed as COMSTAR port provider. 4.7 Interface table ++-- Interface | Classification | Comments ++-- fcadm(1M) forcelip| Committed | Section 4.4 || FCTIO_FORCE_LIP Ioctl | project private| Section 4.5 || Sun_HBA_ForceLip | project private| Section 4.6 5. Reference Documents: PSARC 2004/291 Fibre Channel HBA Port Utility PSARC/2007/501 N_Port_ID Virtualization for Solaris PSARC/2007/523 COMSTAR: Common Multiprotocol SCSI Target PSARC/2008/187 fcinfo(1M) support on a target mode port 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
Management Network Address for COMSTAR logical unit [PSARC/2009/391 Self Review]
Torrey McMahon wrote: Hi John. I can see plenty of use for this but is there a way to not set the field if a customer doesn't want to expose the management URL to the host consuming the LUN? I'd think there might be some more security conscious types that would prefer things that way. It's an optional property. The default would be to not report any URL for the logical unit. - John
Management Network Address for COMSTAR logical unit [PSARC/2009/391 Self Review]
I am sponsoring this case for Bhavyan Bharatharajan and marking it closed approved automatic. This case adds one property to a COMSTAR logical unit to provide support for management URLs. The binding is minor. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Management Network Address for COMSTAR logical unit 1.2. Name of Document Author/Supplier: Author: Bhavyan Bharatharajan 1.3 Date of This Document: 13 July, 2009 4. Technical Description Support for Management Network Address SCSI Vital Product Data (VPD) for COMSTAR logical units. 4.1 Description Adding Management Network Address VPD (85h) support for luns created on a COMSTAR target. This will introduce a new logical-unit-property called mgmt-url for both create-lu and modify-lu subcommands of stmfadm(1M) CLI. This case also introduces a new property called STMF_LU_PROP_MGMT_URL for stmfSetLuProp, stmfModifyLu interfaces in libstmf(3LIB) (see PSARC 2007/523) library 4.2 Bug/RFE Number(s): 6812611 - Add Management Network Address VPD (85h) support to sbd 4.5 Interfaces Minor binding. -+---+- InterfaceClassification Comments -+---+- libstmf | Committed | PSARC 2007/523 | | PSARC 2009/251 | | stmfadm | Committed | PSARC 2007/523 output of| Not an interface| PSARC 2009/251 stmfadm| | -+---+- 4.5.1 stmfGetLuProp(3STMF)/stmfSetLuProp(3STMF) Interfaces Adding new property STMF_LU_PROP_MGMT_URL for stmfGetLuProp(3STMF)/stmfSetLuProp(3STMF) Interfaces 4.5.2 stmfadm(1M) subcommands Adding new logical-unit-property called mgmt-url for create-lu and modify-lu subcommands. 4.6 Doc Impact: 4.6.1 man page Change for stmfadm(1M) _ | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Availability| SUNWstmfu | |_|_| | Interface Stability | Committed | |_|_| information about the new logical-unit-property, mgmt-url need to be added along with existing logical-unit-property description for -p option of both create-lu and modify-lu subcommands. mgmt-url Up to 1024 characters representing Management Network Address URL. More than one URL can be passed using space delimited URLs enclosed inside quotes as a single parameter. 4.6.2 man page change for stmfGetLuProp(3STMF)/stmfSetLuProp(3STMF) | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| Safe| |_|_| Description for the following new property need to be added STMF_LU_PROP_MGMT_URL Up to 1024 characters representing Management Network Address URLs. More than one URL can be passed using space delimited URLs Default: None 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Net 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Net 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
iSCSI initiator tunables [PSARC/2009/369 FastTrack timeout 07/01/2009]
This case has timed out with a +1 and has been marked closed approved. - John
iSCSI initiator tunables [PSARC/2009/369 FastTrack timeout 07/01/2009]
I am sponsoring this fasttrack for Zhang Yi. Requested binding is Patch/Micro.
Timeout is 07/01/2009.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
iSCSI initiator tunables
1.2. Name of Document Author/Supplier:
Author: Zhang Yi
1.3 Date of This Document:
24 June, 2009
2. Project Summary
2.1. Project Description
This project proposes a new management interface to configure several
parameters specific for iSCSI initiator to access a given iSCSI target.
Together with the IMA specification[1] API, management interfaces
are exported in library libima[2] to manage tunable parameters. And
those tunable parameters can be dynamically applied to the iSCSI
initiator driver via iscsiadm or other utilities using the exported
library interface from this project.
4. Technical Description
4.1. Details:
Currently most parameters related to the connection behavior between
the iSCSI initiator and the iSCSI target are hardcoded. It makes iSCSI
initiator in Solaris inflexible to handle various scenarios. For
example, the fixed iSCSI initiator connection retry timer (3 min) is
not suitable in the follow scenarios:
a. Mirrored ZFS over different iSCSI devices. If one of the mirrored
iSCSI devices goes offline, on initiator side whole ZFS pool may
hang for 3 minutes in IO timeout before ZFS degrade the iSCSI
device. Here a shorter timeout value is desirable for this case.
b. iSCSI quorum device on Sun Cluster. If iSCSI quorum device spend
more than 3 minutes to reboot, Cluster node could never online
this iSCSI quorum device after 3 minutes connection retry timeout.
Here a longer timeout value is needed.
This project will add a new option named -T for 'iscsiadm' utility
to set these tunable parameters for iSCSI initiator node or a
specified iSCSI target. And tunable parameters will be applied to
iSCSI initiator driver in real time without reboot.
A programmatic interface is also offered through SUN_IMA library.
The modification of 'iscsiadm' will be based on this interface.
*) CLI interface for 'iscsiadm' utility
Apply tunable parameters to a specific target by using:
iscsiadm modify target-param -T tunable-prop=value \
target-name...
Apply tunable parameters to initiator node by using:
iscsiadm modify initiator-node -T tunable-prop=value.
List specific tunable parameters applied to given target by using:
iscsiadm list target-param -v [target-name..].
List tunable parameters to initiator node by using:
iscsiadm list initiator-node.
Example:
Change maximum connection retry time to 30 seconds for iSCSI target
iqn.1986-03.com.sun:2501.600a0b800049c94 will use follow command:
#iscsiadm modify target-param -T connloginmax=30 \
iqn.1986-03.com.sun:2501.600a0b800049c94
Currently supported tunable-prop parameters are listed below
with corresponding descriptions.
Tunable Parameter Short Description
---
recvloginrsptimeoutSession Login Response Time
connloginmax Maximum Connection Retry Time
pollinglogindelay Login Retry Time Interval
The recvloginrsptimeout is to specify how long iSCSI initiator
will wait for the response of iSCSI session login request from
the given iSCSI target. Valid value is from 0 to 60*60, default
to 60 seconds.
The connloginmax is used to determine maximum iSCSI initiator
connection retry time when iSCSI initiator to target IO timeout
or connection failure. Valid value is from 0 to 60*60, default to
180 seconds.
The pollinglogindelay is used to decide time interval between
each iSCSI session login retry when iSCSI initiator to target IO
timeout or connection failure. Valid value is from 0 to 60*60,
default to 60 seconds.
More tunable parameters can be added using the same mechanism
introduced by this project in case there are new requirements
from customer.
*) Programmatic interface for tunable parameters
Programmatic interface API name with new data structure are
defined in the exported new public header file libsun_ima.h,
typedef enum {
ISCSI_RX_TIMEOUT_VALUE = 1,
iSCSI initiator tunables [PSARC/2009/369 FastTrack timeout 07/01/2009]
Garrett D'Amore wrote: Case looks straight-forward, but the tunable names for use on the CLI are rather awkward. In other instances you have separated multi words such as target-param with hyphens, whereas your tunables are all jammed together. I'd recommend tweaking the names somewhat to make them more readable/user-friendly. Yes, sounds reasonable. An updated fasttrack is in the materials directory with hyphen separated tunable names for the CLI option argument. - John
T11 Storage Management HBA API(SM-HBA) [PSARC/2008/687 FastTrack timeout 06/04/2009]
This case has timed out with a +1 and no issues and has been marked closed approved. - John
T11 Storage Management HBA API(SM-HBA) [PSARC/2008/687 FastTrack timeout 06/04/2009]
The project team would like to make an amendment to this fasttrack as specified below. The project has not yet delivered. I'm reopening the fasttrack and setting the timeout for 06/04/2009. I've placed the updated materials in the case directory. - John --- sasinfo enhancements for HBA and expander representation The sasinfo utility is provided as part of SAS HBA management project(PSARC/2008/687). Originally it provided subcommands for Host Bus Adapter(HBA) ports, remote ports, logical units. As the project copes with the associated SAS device management framework, the need for more granular discovery is identified to help an admin discover SAS topology through the utility. The enhancements are to add - HBA discovery to properly report dynamic HBA port creation/removal of SAS HBA. - explicit expander layer discovery to better handle SAS configuration with multiple layers of expanders - target port centric topology view. Note that the remote-port subcommand which used to cover both expander devices and target ports is removed and the logical-unit subcommand remains the same. - Subcommand Details Note that the comment section indicate if a subcommand or an option is new. -+-+- subcommands/options | Classification | Comments -+-+- | | sasinfo hba| Committed | reports HBA list. subcommand | | | | -v, --verbose | Committed | reports HBA list with | | details. | | (new subcommand) | | sasinfo hba-port | Committed | reports HBA port list. subcommand | | | | -v, --verbose | Committed | reports HBA list with | | details. | | -a, --hba | Committed | filters HBA ports per the | | given | | HBA name. (new option) | | sasinfo expander | Committed | reports expanders subcommand | | discovered on | | an HBA port.(new | | subcommand) | | -v, --verbose | Committed | reports expanders | | discovered on | | an HBA port with details. | | -p, --hba-port | Committed | filters expanders per the | | given HBA port name. | | -t, --target-port| Committed | reports discovered target | | ports on an expander. | | sasinfo target-port | Committed | reports target port list subcommand| | discovered on a host. | | (new subcommand) | | -v, --verbose | Committed | reports target port list | | discovered on a host with | | details | | -s, --scsi | Committed | reports target-port list | | discovered on a host with | | SCSI information. | | sasinfo logical-unit| Committed | reports logical unit list. subcommand | | | | -v, --verbose | Committed | reports logical unit list | | discovered on a host with | | details | | sasinfo output |Not an interface |
T11 Storage Management HBA API(SM-HBA) [PSARC/2008/687 FastTrack timeout 01/29/2009]]
The project team would like to make an amendment to this fasttrack as specified below. I believe this qualifies for self-review and does not need a separate fasttrack. The project has not yet integrated. An updated fasttrack has been placed in the materials directory. Let me know if there are any technical objections. - John === Remove support for SM-HBA Event Related APIs The fasttrack PSARC/2008/687 was submitted for T11 Storage Management HBA API(SM-HBA) support on Solaris. Support for the following optional interfaces will not be provided at this time and will be added and ARC'ed at a later date: - RegisterForAdapterAddEvents - RegisterForAdapterEvents - RegisterForAdapterPortEvents - RegisterForTargetEvents - RegisterForLinkEvents - RemoveCallback No other areas are affected by this change. ===
libstmf/stmfadm enhancements for COMSTAR [PSARC/2009/251 FastTrack timeout 04/29/2009]
This case was approved at PSARC today. - John
libstmf/stmfadm enhancements for COMSTAR [PSARC/2009/251 FastTrack timeout 04/29/2009]
I am sponsoring the following fasttrack for myself. Requested binding is minor. Timeout is set for 4/29. - John Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libstmf/stmfadm enhancements for COMSTAR 1.2. Name of Document Author/Supplier: Author: John Forte 1.3 Date of This Document: 21 April, 2009 4. Technical Description libstmf/stmfadm enhancements for COMSTAR 4.1 Description libstmf(3LIB) was introduced in PSARC 2007/523 but lacked any C interfaces for managing create/delete/modify of sbd (PSARC 2008/235) logical units. sbdadm(1M) is currently the only interface available for managing logical units. This case introduces new library interfaces for managing logical units and introduces new subcommands to stmfadm(1M) to provide CLI support. The new stmfadm(1M) subcommands will be the preferred approach and this case will make sbdadm's stability classification obsolete committed. This does not introduce any backward incompatibility with the existing sbdadm functionality. All existing sbdadm functionality will be carried forward to stmfadm(1M). This case also introduces two library interfaces for managing configuration persistence allowing a developer to provide their own means of persisting configuration data for the stmf service. 4.2 Interfaces Minor binding. -+---+- InterfaceClassification Comments -+---+- libstmf | Committed | PSARC 2007/523 | | stmfadm | Committed | PSARC 2007/523 output of| Not an interface| stmfadm| | | | sbdadm | Obsolete Committed | PSARC 2008/235 4.2.1 stmfadm subcommands create-lu [-p, --lu-prop logical-unit-property=val -s, --size size] lu-file delete-lu lu-name... import-lu lu-file modify-lu [-p, --lu-prop logical-unit-property=val -s, --size size, -f, --file] lu-name|lu-file The command man pages are in Appendix A 4.2.2 sbdadm man page change: _ | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Availability| SUNWstmfu | |_|_| ! | Interface Stability | Obsolete Committed | |_|_| + NOTES + This command is obsolete and may be removed in a future release. + Please use stmfadm(1M) for equivalent functionality. 4.2.3 Library interfaces Note: All library interfaces are committed as per libstmf's current interface classification. int stmfCreateLu(luResource hdl, stmfGuid *luGuid); int stmfCreateLuResource(uint16_t type, luResource *hdl); int stmfDeleteLu(stmfGuid *luGuid); int stmfFreeLuResource(luResource hdl); int stmfGetLuProp(luResource hdl, uint32_t prop, char *propVal, size_t *propLen); int stmfGetLuResource(stmfGuid *luGuid, luResource *hdl) int stmfGetPersistMethod(uint8_t *persistType, boolean_t serviceState); int stmfModifyLu(stmfGuid *luGuid, uint32_t prop, const char *propVal); int stmfSetLuProp(luResource hdl, uint32_t prop, const char *propVal); int stmfSetPersistMethod(uint8_t persistType, boolean_t serviceSet); The interface man pages are in Appendix B. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Net 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open Appendix A == create-lu [-p, --lu-prop logical-unit-property=val -s, --size size] lu-file Create a logical unit that can be registered with STMF. For the -p option, logical-unit-property can be one of the following properties: alias Up to 255 characters representing a user defined name for the device Default: set to file name of backing store blk Block size. Specifies the block size for the device. Default: 512 guid 32 hexadecimal ascii characters representing a valid NAA Registered Extended Identifier Default: set by framework to a generated value meta Metadata file name. When specified, will be used to hold the SCSI metadata for the logical unit. Default: None oui Organizational Unique Identifier. 6
COMSTAR Infiniband SRP Target [PSARC 2009/111 FastTrack timeout 02/25/2009]
I am sponsoring this fasttrack for Peter Cudhea. Requested binding is Patch, timeout is 02/25/2009. There is an IO controller profile attributes table, described in section 4.2.3, in the case materials directory. - John This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: COMSTAR Infiniband SRP Target 1.2. Name of Document Author/Supplier: Peter.Cudhea at sun.com 1.3. Date of This Document: 02/12/09 4. Technical Description COMSTAR Infiniband SRP Target - 4.1. Problem OpenSolaris currently lacks a target driver for the SCSI RDMA Protocol (SRP). SRP accelerates the SCSI protocol by mapping the data transfer phases of SCSI commands to RDMA operations. As a result an SRP initiator should be able to read and write data from a COMSTAR SRP target at high data rates with relatively low CPU utilization. SRP is an alternative to iSER (PSARC 2008/395) for accessing SCSI storage over an Infiniband fabric. Both protocols are seeing demand in the market. In particular, we need an SRP target in COMSTAR (PSARC 2007/523) to enable VMware connectivity to OpenSolaris based open storage. VMware ESX, for example, supports only SRP (not iSER) for block-based storage connectivity over Infiniband. 4.2. Proposal The project will deliver a target implementation of SCSI RDMA Protocol represented as a COMSTAR STMF port provider. We include a minimal implementation of the Infiniband Device Management Agen as a consumer to IBTF (PSARC 2002/132). This agent allows initiator systems to query the capabilities of the target. The SRP port provider will register its targets with the IB DM Agent to allow the targets to be discovered by SRP initiators. 4.2.1. COMSTAR SRP Target (srpt) When the SRP target service is enabled, it will register as a COMSTAR port provider using STMF. This port provider will use the IB transport framework (IBTF) to enumerate all the HCAs on the system by GUID. Each IB HCA will be reflected to STMF as a COMSTAR target named 'eui.HCA-GUID'. For example, for an IB HCA with a HCA GUID of 0003BA0001002E49 the STMF target name will be 'eui.0003BA0001002E49'. STMF commands may then be used to assign these targets to host groups and to create views that determine which backing stores are accessible to which targets. STMF commands may also be used to mark each target as either offline or online. All of the physical IB ports on an HCA will treated as part of the same STMF target. In IB target terms, each Host Channel Adapter (HCA) is treated as a Target Channel Adapter (TCA) with a single IO Unit containing a single IO controller. Multiple physical ports on the HCA are not exposed as separate virtual target-side resources. When the SRP service is enabled and the STMF target for a particular HCA is marked online, each port on that HCA will be configured to listen for incoming connections to the SRP service. A virtual I/O Controller representing the target will also be registered with the minimal IB DM Agent as described in section 4.2.2. The SRP target capability will be represented as an SMF service using the FMRI svc:/system/ibsrp/target:default. This service will be disabled by default. No new 'rights profiles' will be defined; each administrative method for this service (e.g. start and stop) will use a credential with user=root, group=root, and privileges=basic,sys_devices. The ibsrp/target service will be dependent on STMF (svc:/system/stmf:default) and on the IB Device Management Agent described in section 4.2.2 (svc:/system/ibdma:default). The SRP target will be implemented as pseudo device driver 'srpt' which is a child under the Infiniband 'ib' nexus. 4.2.2 Minimal Infiniband Device-Management Agent (ibdma) In order for IB initiators to enumerate the available storage, this project also includes a minimal device management agent for Infiniband, as described in section 16.3 of the Infiniband Architecture Spec. (Section 16.3 corresponds to version 1 of the IB Device Management protocol, which is distinct from the version 2 Device Management protocol as defined in Annex A8.) Infiniband device management services are used by IB initiator systems to enumerate the IO Units (IOUs) and IO Controllers (IOCs) on the target system, and to query the services supported on each IO Controller. For this case, SRP initiators in particular use DM services to enumerate all the IOCs that are SRP-capable IOCs, and to enumerate the SRP services that are available through each IOC. SRP is the only target-side service that makes use of IB DM services for discovery that the Infiniband group expects OpenSolaris to support. If
PSARC/2008/687 T11 Storage Management HBA API(SM-HBA)
This fasttrack was approved in PSARC today. - John
T11 Storage Management HBA API(SM-HBA) [PSARC/2008/687 FastTrack timeout 01/29/2009]]
I am sponsoring this fasttrack for Hyon Kim. Requested binding is Patch, timeout is 01/29/2009. - John This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: T11 Storage Management HBA API(SM-HBA) 1.2. Name of Document Author/Supplier: Author: Hyon Kim 1.3 Date of This Document: 22 January, 2009 4. Technical Description - Problem Area: The currently released Serial Attached SCSI(SAS) HBAs are supported through HBA vendor specific utilities. As Sun is working on release of next generation SAS HBAs the administrator may have to deal with additional vendor specific utilities without common Solaris management support. This project is to deliver T11 Storage Management HBA API(SM-HBA) support and provide standard based SAS management utility for upcoming Sun's SAS-2 compliant (SAS Gen-2) HBAs. Note that a draft of SM-HBA-2 is published but it is not mature enough to guide product implementation according to T11. It is currently put on hold. The project team is requesting micro/patch binding. - Technical description 1. Deliverables: The SM-HBA support comprised of SM-HBA common library, a vendor specific library(VSL) for SAS Gen-2 HBAs and CLI which consumes SM-HBA interfaces and reports SAS HBAs and target configuration. libsmhba.so : SM-HBA common library Exports standard defined interfaces for use by utilities, SMI-S agents and any other 3rd party vendor application. libsun_sas.so : Vendor Specific Library(VSL) for SAS Gen-2 HBAs sasinfo.1M : SM-HBA based CLI for SAS HBA configuration discovery. +===+ +---+ || sasinfo.1M || | other clients | +===+ +---+ | | +==+ || libsmhba.so(SM-HBA standards) || +==+ | +==+ || libsun_sas.so(SAS VSL) || +==+ | | __|__|_ | | For SCSI passthru | +-+ private ioctl | | libdevinfo(PSARC/2004/169) | | | libkstat(PSARC/1999/495)| | | libsysevent(PSARC/2001/076) | | +-+ | | | | Generating devinfo nodes/properties, | | kstat counter and sysevent. | | +--+ | PSARC/2008/672 thebe SAS/SATA driver | | PSARC/2008/448 LSI MPT 2.0 support | | SAS Gen-2 HBA driver | +--+ 2. In Scope: The SM-HBA standard has been evolved from its predecessor FC-HBA to allow an application to manage both SAS and Fibre Channel HBAs through common interfaces. This project is to take advantage of those newly defined interfaces for SAS HBA management and will be providing VSL and CLI for Sun's SAS Gen-2 HBA support. Even though the SM-HBA standard includes the functionality of FC-HBA for FC HBA support, interface-wise it doesn't provide backward compatibility for FC-HBA clients. Thus the SM-HBA library will be handled as a major new release over the existing FC-HBA library. 3. Out of Scope: The FC HBA support through SM-HBA on existing FC HBAs not part of this project. They will be supported through existing libhbaapi.3LIB and fcinfo.1M. Since the functionality for FC support is same as FC-HBA there is no real benefit of migrating current FC-HBA support to SM-HBA. The current FC-HBA clients can continue to use FC-HBA library and if there is any client which needs to manage both FC and SAS through common interfaces in the future, the migration for the current FC-HBA support will be considered. 4. Interfaces: Interfaces Imported -++- Interface| Classification | Comments -++- || Libraries listed || section 4.8| Committed | || Events listed in || section 4.8| Consolidation | | private| Interfaces Exported -++- Interface| Classification | Comments
T11 Storage Management HBA API(SM-HBA) [PSARC/2008/687 FastTrack timeout 01/29/2009]]
Garrett D'Amore wrote: Apparently there is a man page for sasinfo in the materials directory. Might have been nice to note that in the text of the case proper. Agreed. That's my fault, sorry. The rest looks OK. Are we anticipating future projects to use this library, or 3rd party consumption of the library? FC-HBA (libhbaapi(3LIB)) has a few consumers in the OpenSolaris source today, such as cfgadm, fcinfo and luxadm, and also has a number of 3rd party consumers of which we're aware so we would expect the same for this library down the road. One likely future candidate I can think of would be the host SMI-S providers for Fibre Channel and SAS when that eventually gets off the ground. - John
iSCSI Port Provider for COMSTAR [PSARC/2008/587 Self Review]
I'm sponsoring this case for Peter Dunlap and marking it closed approved automatic as it represents no interface changes to the PSARC case it modifies (2008/395) and only splits off the iSER portion from the iSCSI port provider. The addition of iSER adds no interfaces to the existing PSARC case. The release binding is minor. If anyone disagrees with this being closed approved automatic, I'll set the timer. - John Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iSCSI Port Provider for COMSTAR 1.2. Name of Document Author/Supplier: Author: Peter Dunlap 1.3 Date of This Document: 16 September, 2008 4. Technical Description Background -- The COMSTAR (Common Multiprotocol SCSI target PSARC 2007/523) project introduced a modular SCSI target framework to Solaris. COMSTAR allows a Solaris system to act as a block storage SCSI device, analagous to a disk array. Currently COMSTAR supports only Fibre Channel transport. In COMSTAR terminology, a transport plug-in is called a port provider. PSARC 2008/395 iSER: iSCSI Extensions for RDMA describes a project to develop an iSER initiator and iSER target implementation and was approved on 7/9/2008. The iSER initiator will be based on the existing iSCSI initiator modified for iSER transport. In addition, the project delivers an iSCSI port provider to COMSTAR and the iSER target will consist of that iSCSI port provider combination with an iSER transport module. The iSCSI port provider is useful by itself (without iSER) to provide iSCSI transport access to COMSTAR logical units. _ ___ | | | | +-| libstmf | | libiscsit |-+ | |_| |___| | | | | User Space | |---| | Kernel Space | | __ | | | | | | |sbd | | | | block/disk | | | | LU Provider | | | |__| | | | | --- LU Provider Interface --- | | __ | | | | | +-| STMF | | |__| | | -- Port Provider Interface -- | __ __ | | | | | | |fct | | iscsit | | | FC Port| | iSCSI Port |+ | Provider | | Provider | |__| |__| Proposal The project team would like to deliver PSARC 2008/395 in multiple phases. This case represents represents the first phase and will deliver the basic iSCSI port provider itself along with the library and management CLI. This initial integration will include: iSCSI port provider itadm CLI libiscsit Release binding --- A minor release binding is requested Interfaces Exported Interface Classification Comments itadm Committed See itadm(1m) man page itadm CLI outputNot an Interface libiscsit Committed 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS/Net 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
libstmf enhancement for provider data [PSARC/2008/434 Self Review]
Joseph Kowalski wrote: John Forte wrote: stmfGetProviderData(3STMF) . . . NOTES This interface is deprecated in favor of stmfGetProviderDataProt(3STMF) and may be removed in a future revision of libstmf(3LIB). stmfGetProviderData(3STMF) . . . NOTES This interface is deprecated in favor of stmfSetProviderDataProt(3STMF) and may be removed in a future revision of libstmf(3LIB). Shouldn't there be attribute sections on these pages as well, with the stability of obsolete committed? - jek3 Yes, thanks. Updated materials are in the case directory. - John
libstmf enhancement for provider data [PSARC/2008/434 Self Review]
I am self-sponsoring this case. The case adds two committed interfaces to libstmf(3LIB). The binding is patch as is the original case PSARC/2007/523. Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libstmf enhancement for provider data 1.2. Name of Document Author/Supplier: Author: John Forte 1.3 Date of This Document: 09 July, 2008 4. Technical Description SUMMARY This case adds two new interfaces to libstmf (PSARC 2007/523) for managing provider data for concurrent clients. PROBLEM There are two existing interfaces (stmfGetProviderData(3STMF), stmfSetProviderData(3STMF)) that enable a client to get and set provider data. Unfortunately there is no mechanism by which a client issuing a set operation can determine whether the set is in conflict with another client issuing a set operation on the same provider data, i.e. a set of stale data. PROPOSED SOLUTION Two new interfaces (stmfGetProviderDataProt(), stmfSetProviderDataProt()) provide the caller with a token to be retrieved on get and passed on set that will enable the client to determine on set whether the data retrieved from the get matching the passed token is not stale. If the token is no longer valid, the call to set will fail with STMF_ERROR_PROV_DATA_STALE. Alternately, the token may be set to NULL by the caller for the get or set which will effectively revert these calls to stmfGetProviderData() and stmfSetProviderData() respectively. This case will deprecate stmfGetProviderData(3STMF) and stmfSetProviderData(3STMF). MANPAGE ADDITIONS stmfGetProviderDataProt(3STMF): NAME stmfGetProviderDataProt - retrieve the data for the specified provider SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfGetProviderDataProt(char *providerName, nvlist_t **nvl, int providerType, uint64_t *token); PARAMETERS providerNameThe name of the provider for which data is being retrieved. nvl A pointer to a pointer to an nvlist_t. On success, this will contain the nvlist retrieved. Caller is responsible for freeing the returned nvlist by calling nvlist_free(3NVPAIR). providerTypeThe value for this parameter must be either STMF_LU_PROVIDER_TYPEor STMF_PORT_PROVIDER_TYPE. token A pointer to a uint64_t allocated by the caller. On success, this will contain a token for the returned data that can be used in a call to stmfSetProviderDataProt(3STMF) to ensure that the data returned in this call is not stale. If this value is NULL, the token will be ignored. DESCRIPTION The stmfGetProviderDataProt() function retrieves the data for the specified provider. RETURN VALUES The following values are returned: STMF_ERROR_NOMEMThe library was unable to allocate sufficient memory to return the data. STMF_STATUS_SUCCESS The API call was successful. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: _ | ATTRIBUTE TYPE| ATTRIBUTE VALUE | |_|_| | Interface Stability | Committed | |_|_| | MT-Level| Safe| |_|_| SEE ALSO libstmf(3LIB), nvlist_free(3NVPAIR), attributes(5) stmfSetProviderDataProt(3STMF): NAME stmfSetProviderDataProt - retrieve the data for the specified provider SYNOPSIS cc [ flag... ] file... -lstmf [ library... ] #include libstmf.h int stmfSetProviderData(char *providerName, nvlist_t **nvl, int providerType, uint64_t *token); PARAMETERS providerNameThe name of the provider for which data is being retrieved. nvl A pointer to a an nvlist_t containing the nvlist to be set. providerTypeThe value
PSARC/2008/235 SCSI Block Disk Provider for COMSTAR
This fasttrack was approved in PSARC today. - John
2008/235 [SCSI Block Disk Provider for COMSTAR]
Glenn Skinner wrote: Date: Tue, 01 Apr 2008 17:11:06 -0700 (PDT) From: John Forte jforte at sac.sfbay.sun.com Subject: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] ... 1. Summary This command (sbdadm) and associated driver (sbd) will provide SCSI block disk device support for COMSTAR (PSARC/2007/523). The command sbdadm(1M) will provide support for creating logical units utilizing any file or raw block device as the backing store. Logical units created with sbdadm will be available to the COMSTAR framework and can be further managed and provisioned to storage clients in the network using stmfadm(1M). Logical units created with sbdadm(1M) are persistent across reboots. How is persistence accomplished? That is, where and how is the state stored? I didn't see any mention of that in the interface table. The specific library interfaces are not listed in the interface table but the support is provided by libstmf. The interfaces that provide the support are: stmfGetProviderData() stmfSetProviderData() - John
SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack]
I am sponsoring this fasttrack for Sumit Gupta. Requested binding is Patch, timeout is 04/09/2008 - John Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SCSI Block Disk Provider for COMSTAR 1.2. Name of Document Author/Supplier: Author: Sumit Gupta 1.3 Date of This Document: 01 April, 2008 4. Technical Description SCSI Block Disk Provider for COMSTAR 1. Summary This command (sbdadm) and associated driver (sbd) will provide SCSI block disk device support for COMSTAR (PSARC/2007/523). The command sbdadm(1M) will provide support for creating logical units utilizing any file or raw block device as the backing store. Logical units created with sbdadm will be available to the COMSTAR framework and can be further managed and provisioned to storage clients in the network using stmfadm(1M). Logical units created with sbdadm(1M) are persistent across reboots. 2. Documentation NAME sbdadm - SCSI Block Disk Command Line Interface SYNOPSIS sbdadm create-lu [-s, --size size] filename sbdadm delete-lu lu_name sbdadm import-lu lu_name sbdadm list-lu sbdadm modify-lu [-s, --size size] lu_name|filename DESCRIPTION The sbdadm command provides the ability to create SCSI disk type Logical Units and register them with the SCSI Target Mode Framework described by stmf(7D) so that they can be exposed outside of the Solaris host to other initiators on the storage network. The SCSI Logical Unit thus created uses the specified file as its backing store to store the logical unit data. The size of the Logical Unit is derived from the size of the file minus 64K to store the control information for the Logical Unit. The size of the Logical unit can also be specified by the command line option in which case it is possible to create Logical Units without initially occupying any physical storage. The maximum supported size for a Logical Unit is 8 Exabytes. filenameName of an existing file or a fully qualified path to a raw block device. lu_name The 32-byte hexadecimal representation of the logical unit. This is available in the output of sbdadm create-lu or from sbdadm list-lu. This 32-byte hexadecimal representation will also be available using the stmfadm(1M) command. SUBCOMMANDS sbdadm -? sbdadm create-lu [-s, --size size] filename Create a logical unit that can be registered with stmf(7D). -s, --size size size is an integer value which can be followed by one of the following letters to indicate : k kilobyte m megabyte g gigabyte t terabyte p petabyte e exabyte If this option is not specified, size defaults to the size of filename. The size specified may exceed the size of the file or device. sbdadm delete-lu lu_name Delete an existing logical unit that was created using sbdadm create. This removes the logical unit from stmf. Any existing data on the logical unit remains intact. sbdadm import-lu filename Imports and loads a logical unit into stmf that was previously created using sbdadm create and since deleted from stmf using sbdadm delete. On success, the logical unit is again made available to stmf. filename is the filename that was used in the sbdadm create-lu command for this logical unit. sbdadm list-lu List all logical units that were created using the sbdadm create command. sbdadm modify-lu [-s, --size lun_sizek/m/g/t] lu_name|filename Modifies attributes of an existing logical unit created using the sbdadm create command. -s, --size size lun_size is an integer value followed by one of the following letters to indicate : k kilobyte m megabyte g gigabyte t terabyte p petabyte e exabyte When this option is specified, the existing
