From jforte@sac.sfbay.sun.com Mon Jul 20 10:25:49 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KHPnuF028814 for ; Mon, 20 Jul 2009 10:25:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6KHPm4Z014093; Mon, 20 Jul 2009 10:25:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN30050JCF09Z00@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Jul 2009 10:25:48 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN300HDRCF0NOF0@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Jul 2009 10:25:48 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6KHPkk1006729; Mon, 20 Jul 2009 10:25:46 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KHPjCP028809; Mon, 20 Jul 2009 10:25:45 -0700 (PDT) Received: (from jforte@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n6KHPjUn028805; Mon, 20 Jul 2009 10:25:45 -0700 (PDT) Date: Mon, 20 Jul 2009 10:25:45 -0700 (PDT) From: John Forte Subject: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] To: PSARC-ext@sun.com Cc: reed.liu@sun.com Message-id: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4110 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 From gdamore@Sun.COM Mon Jul 20 10:49:55 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KHns0a029294 for ; Mon, 20 Jul 2009 10:49:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6KHnXrl008607 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Jul 2009 01:49:54 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN300F13DJ3G500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Mon, 20 Jul 2009 11:49:51 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN300KRXDJ3Q4B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Mon, 20 Jul 2009 11:49:51 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6KHno5H028946 for ; Mon, 20 Jul 2009 10:49:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300600DBBJ000@fe-sfbay-09.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Mon, 20 Jul 2009 10:49:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN300CMGDIW23E0@fe-sfbay-09.sun.com>; Mon, 20 Jul 2009 10:49:48 -0700 (PDT) Date: Mon, 20 Jul 2009 10:49:44 -0700 From: "Garrett D'Amore" Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> Sender: Garrett.Damore@Sun.COM To: John Forte Cc: PSARC-ext@Sun.COM, Reed.Liu@Sun.COM Message-id: <4A64AE38.1000907@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4838 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 > From John.Forte@sun.com Mon Jul 20 11:05:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KI5ECk029968 for ; Mon, 20 Jul 2009 11:05:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6KI5AnR056192 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Jul 2009 12:05:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN30070RE8PHI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 11:05:13 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN300LJ4E8PE230@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 11:05:13 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6KI5Dl8022269 for ; Mon, 20 Jul 2009 18:05:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300I00E6WH300@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:05:13 -0600 (MDT) Received: from [129.146.56.52] ([unknown] [129.146.56.52]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN3002WVE8OXJ40@mail-amer.sun.com>; Mon, 20 Jul 2009 12:05:12 -0600 (MDT) Date: Mon, 20 Jul 2009 11:03:17 -0700 From: John Forte Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64AE38.1000907@sun.com> Sender: John.Forte@sun.com To: "Garrett D'Amore" , Reed.Liu@sun.com Cc: John Forte , PSARC-ext@sun.com Message-id: <4A64B165.4060000@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 988 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 From gdamore@sun.com Mon Jul 20 11:11:36 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KIBZUt029995 for ; Mon, 20 Jul 2009 11:11:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6KIBXQQ019418 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Jul 2009 02:11:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN30080NEJ82W00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 11:11:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN3006G0EJ82M20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 11:11:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6KIBWYa007783 for ; Mon, 20 Jul 2009 11:11:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300E00EENN300@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 11:11:32 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN3009WNEJ3QAG0@fe-sfbay-10.sun.com>; Mon, 20 Jul 2009 11:11:28 -0700 (PDT) Date: Mon, 20 Jul 2009 11:11:27 -0700 From: "Garrett D'Amore" Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64B165.4060000@sun.com> Sender: Garrett.Damore@sun.com To: John Forte Cc: Reed.Liu@sun.com, John Forte , PSARC-ext@sun.com Message-id: <4A64B34F.2040105@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1559 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. >> >> 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. Cool! Thanks for the clarification. - Garrett > > - John From John.Forte@sun.com Mon Jul 20 12:11:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KJBQWe006827 for ; Mon, 20 Jul 2009 12:11:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6KJBLsA004531 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Jul 2009 20:11:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN300B0FHB0Q300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:11:24 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN3006ZHHB02C60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:11:24 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6KJBNUo001562 for ; Mon, 20 Jul 2009 19:11:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300300GQRIU00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 13:11:23 -0600 (MDT) Received: from [129.146.56.52] ([unknown] [129.146.56.52]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN3006U0HAYYU40@mail-amer.sun.com>; Mon, 20 Jul 2009 13:11:23 -0600 (MDT) Date: Mon, 20 Jul 2009 12:09:28 -0700 From: John Forte Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64B34F.2040105@sun.com> Sender: John.Forte@sun.com To: "Garrett D'Amore" Cc: Reed.Liu@sun.com, John Forte , PSARC-ext@sun.com Message-id: <4A64C0E8.4060204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> <4A64B34F.2040105@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 2138 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 From Torrey.McMahon@sun.com Mon Jul 20 12:11:31 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KJBUXa007359 for ; Mon, 20 Jul 2009 12:11:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6KJBKVL019680 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Jul 2009 03:11:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN300113HB41800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 13:11:28 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN300MBEHB31V10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 13:11:27 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6KJBRlQ019826 for ; Mon, 20 Jul 2009 19:11:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300L00GG87S00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 13:11:27 -0600 (MDT) Received: from [192.168.0.198] ([unknown] [69.143.10.149]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN3001FIHAM3U10@mail-amer.sun.com>; Mon, 20 Jul 2009 13:11:11 -0600 (MDT) Date: Mon, 20 Jul 2009 15:11:10 -0400 From: Torrey McMahon Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64B34F.2040105@sun.com> Sender: Torrey.McMahon@sun.com To: "Garrett D'Amore" Cc: John Forte , Reed.Liu@sun.com, John Forte , PSARC-ext@sun.com Message-id: <4A64C14E.5060602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> <4A64B34F.2040105@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) Gecko/20090718 Lightning/1.0pre Shredder/3.0b4pre Status: RO Content-Length: 1633 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? 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. From gdamore@Sun.COM Mon Jul 20 12:17:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KJHXmu004423 for ; Mon, 20 Jul 2009 12:17:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6KJHLZn007951 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Jul 2009 20:17:32 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN300C0VHL72W00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:17:31 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN3006GEHL52G80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:17:30 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6KJHTjx016154 for ; Mon, 20 Jul 2009 12:17:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300200GK69K00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:17:29 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN3008EHHL5CV00@fe-sfbay-09.sun.com>; Mon, 20 Jul 2009 12:17:29 -0700 (PDT) Date: Mon, 20 Jul 2009 12:17:29 -0700 From: "Garrett D'Amore" Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64C0E8.4060204@sun.com> Sender: Garrett.Damore@Sun.COM To: John Forte Cc: Reed.Liu@Sun.COM, John Forte , PSARC-ext@Sun.COM Message-id: <4A64C2C9.3040502@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> <4A64B34F.2040105@sun.com> <4A64C0E8.4060204@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2468 John Forte wrote: > 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. Okay, as long as it can't cause data loss, I'm fine with it. (The disruption would be expected. :-) Documentation of the disruption details in the man page would be a good idea, though. I'll go ahead and grant my +1 at this point. -- Garrett > > - John From John.Forte@sun.com Mon Jul 20 12:20:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6KJKeNn004476 for ; Mon, 20 Jul 2009 12:20:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6KJKYbv009955 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Jul 2009 20:20:39 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN300L01HQEW300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:20:38 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN300LITHQDE190@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 12:20:38 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6KJKbeC005112 for ; Mon, 20 Jul 2009 19:20:37 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN300J00H1JAG00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 13:20:37 -0600 (MDT) Received: from [129.146.56.52] ([unknown] [129.146.56.52]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN3001F4HQC3U50@mail-amer.sun.com>; Mon, 20 Jul 2009 13:20:37 -0600 (MDT) Date: Mon, 20 Jul 2009 12:18:42 -0700 From: John Forte Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64C14E.5060602@sun.com> Sender: John.Forte@sun.com To: Torrey McMahon Cc: "Garrett D'Amore" , Reed.Liu@sun.com, John Forte , PSARC-ext@sun.com Message-id: <4A64C312.5050403@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> <4A64B34F.2040105@sun.com> <4A64C14E.5060602@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 2068 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 From Reed.Liu@Sun.COM Mon Jul 20 20:56:00 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6L3txaW021076 for ; Mon, 20 Jul 2009 20:56:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6L3txMc064981 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 20 Jul 2009 21:55:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN400B015LBOV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 20:55:59 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN400G055LA3EE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 20:55:59 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6L3tvWX018006 for ; Tue, 21 Jul 2009 03:55:57 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN40000058IG400@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Jul 2009 11:55:57 +0800 (SGT) Received: from [10.13.21.171] ([unknown] [10.13.21.171]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN400KBB5L8BY50@mail-apac.sun.com>; Tue, 21 Jul 2009 11:55:57 +0800 (SGT) Date: Tue, 21 Jul 2009 11:56:20 +0800 From: Reed Liu Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64B165.4060000@sun.com> Sender: Reed.Liu@Sun.COM To: John Forte Cc: "Garrett D'Amore" , John Forte , PSARC-ext@Sun.COM Message-id: <4A653C64.905@sun.com> Organization: CoreIO MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090409) Status: RO Content-Length: 1076 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. >> >> 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? Yes, that's correct. Thanks, -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 From Reed.Liu@sun.com Mon Jul 20 20:58:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6L3wMrp021325 for ; Mon, 20 Jul 2009 20:58:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6L3wKNl009693 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Jul 2009 11:58:21 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN400F015P8T300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 21:58:20 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN4003UO5P7EOE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Jul 2009 21:58:20 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6L3wIH7018103 for ; Tue, 21 Jul 2009 03:58:18 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN400J005EJ6400@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Jul 2009 11:58:18 +0800 (SGT) Received: from [10.13.21.171] ([unknown] [10.13.21.171]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN4001ND5P5FI70@mail-apac.sun.com>; Tue, 21 Jul 2009 11:58:18 +0800 (SGT) Date: Tue, 21 Jul 2009 11:58:40 +0800 From: Reed Liu Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A64C312.5050403@sun.com> Sender: Reed.Liu@sun.com To: John Forte Cc: Torrey McMahon , "Garrett D'Amore" , John Forte , PSARC-ext@sun.com Message-id: <4A653CF0.90308@sun.com> Organization: CoreIO MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> <4A64B34F.2040105@sun.com> <4A64C14E.5060602@sun.com> <4A64C312.5050403@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090409) Status: RO Content-Length: 2198 John Forte wrote: > 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. I see, and I will add this to its manpage. Thanks, -Reed > > - John > From Darren.Moffat@sun.com Tue Jul 21 01:50:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6L8oY2Q000675 for ; Tue, 21 Jul 2009 01:50:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6L8oXu6026752 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Jul 2009 09:50:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN400103J88JO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Jul 2009 01:50:32 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN400F0UJ877N40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Jul 2009 01:50:32 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6L8oUOU019877 for ; Tue, 21 Jul 2009 08:50:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN400G00J3VZI00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Jul 2009 09:50:28 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN400MNZJ7TMJA0@fe-emea-09.sun.com>; Tue, 21 Jul 2009 09:50:17 +0100 (BST) Date: Tue, 21 Jul 2009 09:50:16 +0100 From: Darren J Moffat Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <4A653C64.905@sun.com> Sender: Darren.Moffat@sun.com To: Reed Liu Cc: John Forte , "Garrett D'Amore" , John Forte , PSARC-ext@sun.com Message-id: <4A658148.3020406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> <4A64AE38.1000907@sun.com> <4A64B165.4060000@sun.com> <4A653C64.905@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1322 Reed Liu 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. >>> >>> 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? > Yes, that's correct. There doesn't appear to be an existing RBAC rights profile (exec_attr(4)) entry for fcadm. While this case doesn't make things any worse, since fcadm already exists and luxadm doesn't have an exec_attr(4) profile either, I would really like this situation to be resolved. As such I've logged 6862566 rather than holding this minor case to resolving the situation, the main reason for that is I think the problem is bigger than just fcadm. -- Darren J Moffat From John.Forte@sun.com Wed Jul 22 23:48:44 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6N6mi5s013822 for ; Wed, 22 Jul 2009 23:48:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n6N6miko003001 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Jul 2009 23:48:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KN800J052X77S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 22 Jul 2009 23:48:43 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KN800G4U2X6GQ30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 22 Jul 2009 23:48:42 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6N6mgtV016293 for ; Thu, 23 Jul 2009 06:48:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KN8005002HPDL00@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 23 Jul 2009 00:48:42 -0600 (MDT) Received: from john-fortes-macbook-pro.local ([unknown] [71.139.10.232]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KN8009RC2X5N580@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 23 Jul 2009 00:48:42 -0600 (MDT) Date: Wed, 22 Jul 2009 23:45:25 -0700 From: John Forte Subject: Re: Fibre Channel port link reinitialize support [PSARC/2009/401 FastTrack timeout 07/27/2009] In-reply-to: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> Sender: John.Forte@sun.com To: Reed.Liu@sun.com Cc: PSARC-ext@sun.com Message-id: <4A680705.3030505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907201725.n6KHPjUn028805@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) Status: RO Content-Length: 47 This case was approved at PSARC today. - John