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. 2) Are any additional privileges required for this operation? What are the privileges needed to perform this action? 3) Will the luxadm version of the command be Obsoleted at some point? -- Garrett John Forte wrote: > 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 210000e08b909221 > # > ... > # 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 >