Re: iSCSI-specific unit attention conditions
Julian Satran <[email protected]> Sat, 4 Apr 2009 21:16:29 +0300
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <OF02E6844A.960EF36C-ONC225758E.0062068D-C225758E.006462F4@il.ibm.com> |
This is a multipart message in MIME format. --===============1220397051== Content-Type: multipart/alternative; boundary="=_alternative 0064605FC225758E_=" This is a multipart message in MIME format. --=_alternative 0064605FC225758E_= Content-Type: text/plain; charset="US-ASCII" [email protected] wrote on 04/04/2009 09:29:03: > From: > > "Bill Galloway" <[email protected]> > > To: > > <[email protected]> > > Date: > > 04/04/2009 20:39 > > Subject: > > Re: [Ips] iSCSI-specific unit attention conditions > > Sent by: > > [email protected] > > This is a re-send from a different email.... > > I am the guilty party associated with these sense codes. I have been > traveling for the last few days or I would have chimed in sooner. My > original proposal was not iSCSI specific. It added three ASC/ASCQs which > were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually > explain the intent better (IMHO). > > We produce an iSCSI target with many "Portal Groups" and "Network Portals". > Portal Groups come and go dynamically. Within a Portal Group, Network > Portals come, go, or change dynamically. The intent is for the initiator to > be connected to all Network Portals, on all Portal Groups, all of the time. > This is usually accomplished with some combination of MCS in the initiator > and a MPIO (multipath) layer above the initiator. The initiator is > perfectly willing to make all of these connections but there is no way > specified in any standard to accomplish this task. There is a mix of layers > here that makes for a messy solution. I am certainly open to a better one. > > The SCSI layer could care less about Network Portals coming, going, or > changing but something has to kick the initiator to do a new discovery and > make the appropriate connections. This would have been better handled at > the iSCSI layer but I could find nothing available. In our implementation > the MPIO layer traps these UAs and kicks the initiator. > > The SCSI layer does have a legitimate need to know about Portal Groups > coming and going. These map to SAM target ports and the SCSI layer may need > to know. The initiator also needs to know so that it can make the new > connections. In our implementation the MPIO layer also traps these UAs and > kicks the initiator. > > Why three codes? No good reason. My first proposal was more generic than > iSCSI and there was a hope that it would be useful to other protocols. To > get the proposal passed, I agreed to change the names to be iSCSI specific. > In retrospect when I made the name change, I could have dropped it to one > code. In our current implementation we treat all codes the same. > > I hope this explains the rational for these ASC/ASCQs. I am not aware of > anything in the iSCSI spec that accomplishes these goals. I am certainly > willing to explain further and to work with STORM to document this better > and/or come up with a better solution. > > Bill Galloway > Pivot3, Inc. > BillG[-at-]Pivot3.com > > _______________________________________________ > Ips mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ips The first reaction to your note would be probably that you are right - SCSI is probably the wrong layer to make initiators aware of the existence of a new port. On the other hand any transport than has no "permanent session" (in a generic sense) would have a hard time handling it. And even worse - if the target is connected through different transport to the same or different initiators which one of the transports should carry it (think only about a FCP target that has an iSCSI backup - a not entirely imaginary scenario)? And the ugly part about doing it with UA is that you kick in a recovery process that might be non-trivial. The cleanest solution (for iSCSI) is to relegate the discovery (and change) to an out of band mechanism (as I have advocated for a long time). The drawback is that all the available out-of-band mechanisms are heavy and quite expensive (this is not to be considered a critique - it is just a statement of fact). Alternatively we could choose to handle the iSCSI case exclusively and use a version of one of our messages to convey the change. It will not handle all the cases (as the above FCP - iSCSI mix) but will perhaps solve Bill's problem. Alternatively we might try and persuade T10 (SCSI) do adopt an "in-band" mechanism to prompt (re) discovery that should not carry the UA weight in most of the cases and then make the codes obsolete if the cease to be useful and/or extend them to other transports. The last alternative is to mandate that configuration changes of this type can be made only outside a session - that will require us to use only a change bit from session to session (or login key) to indicate a change or unknown state since last discovery. Julo Julo --=_alternative 0064605FC225758E_= Content-Type: text/html; charset="US-ASCII" <br><tt><font size=2>[email protected] wrote on 04/04/2009 09:29:03:<br> <br> > From:</font></tt> <br><tt><font size=2>> <br> > "Bill Galloway" <[email protected]></font></tt> <br><tt><font size=2>> <br> > To:</font></tt> <br><tt><font size=2>> <br> > <[email protected]></font></tt> <br><tt><font size=2>> <br> > Date:</font></tt> <br><tt><font size=2>> <br> > 04/04/2009 20:39</font></tt> <br><tt><font size=2>> <br> > Subject:</font></tt> <br><tt><font size=2>> <br> > Re: [Ips] iSCSI-specific unit attention conditions</font></tt> <br><tt><font size=2>> <br> > Sent by:</font></tt> <br><tt><font size=2>> <br> > [email protected]</font></tt> <br><tt><font size=2>> <br> > This is a re-send from a different email.... <br> > <br> > I am the guilty party associated with these sense codes. I have been<br> > traveling for the last few days or I would have chimed in sooner. My<br> > original proposal was not iSCSI specific. It added three ASC/ASCQs which<br> > were DEVICE PORT ADDRESS ADDED/CHANGED/REMOVED. The original names actually<br> > explain the intent better (IMHO).<br> > <br> > We produce an iSCSI target with many "Portal Groups" and "Network Portals".<br> > Portal Groups come and go dynamically. Within a Portal Group, Network<br> > Portals come, go, or change dynamically. The intent is for the initiator to<br> > be connected to all Network Portals, on all Portal Groups, all of the time.<br> > This is usually accomplished with some combination of MCS in the initiator<br> > and a MPIO (multipath) layer above the initiator. The initiator is<br> > perfectly willing to make all of these connections but there is no way<br> > specified in any standard to accomplish this task. There is a mix of layers<br> > here that makes for a messy solution. I am certainly open to a better one.<br> > <br> > The SCSI layer could care less about Network Portals coming, going, or<br> > changing but something has to kick the initiator to do a new discovery and<br> > make the appropriate connections. This would have been better handled at<br> > the iSCSI layer but I could find nothing available. In our implementation<br> > the MPIO layer traps these UAs and kicks the initiator.<br> > <br> > The SCSI layer does have a legitimate need to know about Portal Groups<br> > coming and going. These map to SAM target ports and the SCSI layer may need<br> > to know. The initiator also needs to know so that it can make the new<br> > connections. In our implementation the MPIO layer also traps these UAs and<br> > kicks the initiator.<br> > <br> > Why three codes? No good reason. My first proposal was more generic than<br> > iSCSI and there was a hope that it would be useful to other protocols. To<br> > get the proposal passed, I agreed to change the names to be iSCSI specific.<br> > In retrospect when I made the name change, I could have dropped it to one<br> > code. In our current implementation we treat all codes the same.<br> > <br> > I hope this explains the rational for these ASC/ASCQs. I am not aware of<br> > anything in the iSCSI spec that accomplishes these goals. I am certainly<br> > willing to explain further and to work with STORM to document this better<br> > and/or come up with a better solution.<br> > <br> > Bill Galloway<br> > Pivot3, Inc.<br> > BillG[-at-]Pivot3.com<br> > <br> > _______________________________________________<br> > Ips mailing list<br> > [email protected]<br> > </font></tt><a href=https://www.ietf.org/mailman/listinfo/ips><tt><font size=2>https://www.ietf.org/mailman/listinfo/ips</font></tt></a><tt><font size=2><br> </font></tt> <br><tt><font size=2>The first reaction to your note would be probably that you are right - SCSI is probably the wrong layer to make initiators aware of the existence of a new port.</font></tt> <br><tt><font size=2>On the other hand any transport than has no "permanent session" (in a generic sense) would have a hard time handling it.</font></tt> <br><tt><font size=2>And even worse - if the target is connected through different transport to the same or different initiators which one of the transports should carry it (think only about a FCP target that has an iSCSI backup - a not entirely imaginary scenario)?</font></tt> <br> <br><tt><font size=2>And the ugly part about doing it with UA is that you kick in a recovery process that might be non-trivial.</font></tt> <br> <br><tt><font size=2>The cleanest solution (for iSCSI) is to relegate the discovery (and change) to an out of band mechanism (as I have advocated for a long time). The drawback is that all the available out-of-band mechanisms are heavy and quite expensive (this is not to be considered a critique - it is just a statement of fact). Alternatively we could choose to handle the iSCSI case exclusively and use a version of one of our messages to convey the change. It will not handle all the cases (as the above FCP - iSCSI mix) but will perhaps solve Bill's problem.</font></tt> <br> <br><tt><font size=2>Alternatively we might try and persuade T10 (SCSI) do adopt an "in-band" mechanism to prompt (re) discovery that should not carry the UA weight in most of the cases and then make the codes obsolete if the cease to be useful and/or extend them to other transports.</font></tt> <br> <br><tt><font size=2>The last alternative is to mandate that configuration changes of this type can be made only outside a session - that will require us to use only a change bit from session to session (or login key) to indicate a change or unknown state since last discovery.</font></tt> <br> <br><tt><font size=2>Julo</font></tt> <br> <br><tt><font size=2>Julo</font></tt> <br> <br> --=_alternative 0064605FC225758E_=-- --===============1220397051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list [email protected] https://www.ietf.org/mailman/listinfo/ips --===============1220397051==--