|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: login issue - partial consensus callNick, I'm surprised by your comments. I've had some (small) experience with both WinNT and Linux drivers (I've hacked on both) and have used the registry to read configuration information for WinNT and am currently reading a config file for a Linux driver. Even the network drivers in Unix have to read /etc/hostname and other such files. But YMMV. As for the boot issue, this is orthogonal, in my opinion. Boot will always have to work differently (that's why there's a boot draft for iSCSI). What I identify myself as for a boot drive (InitiatorName, ISID) may not be what I use for all other contexts. I can use my boot identity to read enough of the boot image to get my real identity and then reconnect to all my drives (including, perhaps but not necessarily my boot drive) and off I go. I probably won't be able to connect to all my drives right up front anyway (that's not even how any boot works, as far as I know). Typically, boot reads via BIOS just enough to get going on the first disk and then loads the real drivers for each logical unit it finds. The bus scan for the "other logical units" is driven by the kernel (after it loads), not by BIOS. So, you're correct that for just boot I'll need a RAM/BIOS based InitiatorName, but that need not be my "true" identity for access to all drives after kernel boot. But such a BIOS will also have to have a fair chunk of network configuration information, as well as either a static (RAM/BIOS) ipaddress for iSCSI boot disk or will have to have a lot of "discovery" logic (e.g., SLP, iSNS, etc) to find the place that knows where my boot disk is. If I can configure that much, then I can configure an InitiatorName of my true identiry as well (if needed). Additionally, for boot, I only need on connection (this is not really performance path, and I almost surely don't want the complexity of path failover, etc), so I only need one ISID for that (might as well pick ISID=zero). Then I can always have my "on the fly" drivers use non-zero ISID and there will be no collisions with the boot logic. Jim Hafner "Martin, Nick" <Nick.Martin@compaq.com> on 09/10/2001 01:35:27 pm To: Jim Hafner/Almaden/IBM@IBMUS, "'ips@ece.cmu.edu'" <ips@ece.cmu.edu> cc: Subject: RE: iSCSI: login issue - partial consensus call Jim, Although I am not an expert in Microsoft drivers, I have checked with an expert and he confirms that "mini-port" storage drivers for NT4 did not have the ability to "query" the registry using a "key". If a command line for this instance number of this driver is stored in the registry, it will be passed to the driver as it initializes. We have learned not to rely on parameters passed from the registry in the driver command line. There are a number of conditions which can cause this information to be incorrect. (As an example two different controller models supported by the same driver will each be treated as instance 0 and get the same command line.) In my first hand Unix driver experience, I have found it rare for a driver to be able to read a file. If iSCSI is only to be used for secondary or auxiliary storage devices, then utilities running from primary storage can supply the required parameters. However, if iSCSI is to be used for primary storage (i.e. system disk or root disk) then the iSCSI driver in the Initiator can not access parameters stored on that disk to initialize itself before establishing a connection to an iSCSI target. Storage drivers must be able to initialize and operate in the pre-boot and early-boot stages of system initialization before any disks are available. Dependence on parameters not available until the system disk is mounted will prevent iSCSI from being usable as a system disk. IMHO, indicating that these are easy problems with simple elegant solutions seems misleading. I am not saying these problems can not be solved. Administrators can and will configure whatever they are required to configure. If they need it to work, they won't give up until it does. I just want to see that the number of things that must be configured to use iSCSI effectively are kept to a minimum. I hope iSCSI can seem easier to administer than other storage network technologies. Thanks, Nick -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, September 07, 2001 11:23 AM To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu Subject: RE: iSCSI: login issue - partial consensus call Eddy, I have ideas on how this ought to be done, analogous to way that InitiatorName would get assigned. Take WinXX for example, I'd have a well-defined registry key where the miniports would look for their InitiatorName. The install of the first iSCSI miniport driver would look for that key, not find it and then instantiate whatever name is provided by the software installer. After that, any other driver installation (hopefully all driver installers would use the same key) would see that value and accept it. If not, then they could use another vendor-key which would render them as being a 'separate iSCSI Node' (and the conflict issues go away). In a similar way, the registry could hold ranges of ISIDs for each driver that installed. A driver on installation would claim some range of ISID's not already claimed by other drivers. If a driver claimed too many, then the next install might fail or trigger a management interface to reassign. If a driver didn't play by these rules (either because it didn't want to or was broken) then the customer probably get a new vendor! Right now, miniport drivers already get some (typically vendor-specific) information from the registry. There is no reason to believe WE can't cooperate in determining well-known keys for this purpose. I suggested in a private e-mail with David Black that we could make this ISID partitioning assignment a bit easier. For example, if we simply had in the registry a 'counter' for each miniport as it loaded. This counter could map nicely to a Portal Group Tag. Then we embed the portal group tag in the ISID (in some field within the ISID). Then you get explicit partitioning of ISIDs without a direct management interface that can screw up (David's concern). The drivers effectively enumerate themselves (and perhaps multiple portal groups for each driver, as needed) and the rest is for free. I think that drivers already enumerate themselves anyway, so this shouldn't be a problem. Similar things could happen for Unix and friends by just having a defined /etc/initiatorname file and enumeration of the drivers in /dev/iscsi. I didn't think this was such a big deal! Jim Hafner "Eddy Quicksall" <eddy_quicksall@ivivity.com>@ece.cmu.edu on 09/07/2001 06:51:06 am Please respond to <eddy_quicksall@ivivity.com> Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, "Sandeep Joshi" <sandeepj@research.bell-labs.com> cc: <ips@ece.cmu.edu> Subject: RE: iSCSI: login issue - partial consensus call John, We really should do this so a driver can be written for existing OS's. How would you hand out ISIDs when a Miniport is being loaded? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, September 06, 2001 3:21 PM To: Sandeep Joshi Cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call I understand you point, however, the discussion we had on this, talked about each HBA needing to have an install process that is OS specific. It was suppose to be an OS specific install or startup process that handed out the ISIDs (or ISID ranges). I think your point is that you wish that there was no reason to interact with the OS, in order to get installed. I do not think that is a good assumption. It is the OS that needs to let the HBA know what the iSCSI Initiator Node Name is, so that the HBA can configure to use it. It might as well hand out the ISIDs at the same time. You are suggesting that making the ID of the iSCSI HBA only a HW item. This is not where we came down previously. You want to make your job of interfacing with the OS, simpler, and put more burden on the administrator. This was the mistake we made with FC and I would not like to see that repeated here. You say that there needs to be Jumpers or switches, well this is up to your adapter. We use to do that kind of stuff before the Plug and Play started working with the OS. We need to work with the OS in a similar manor. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on 09/06/2001 11:44:00 AM Sent by: sandeepj@research.bell-labs.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: login issue - partial consensus call John, Is this what you are referring to ? (Sec 1.3 of Naming & Discovery) > b) The ISID name space of the iSCSI Initiator should be partitioned > among the intiator portal groups. How do you perceive this will be achieved in practice ? This can turn out to be an nightmare for HBA vendors. IRQ settings, jumpers, or setup programs which run at boot instantly come to mind. Ideally, ISIDs should work as SCAM works but that would involve adding a mid-layer to OSes, to distribute that ISID name space. Modifying OSes in the field is tough, as we all know. I realize the standard wont mandate such configuration items but I'd rather we not add rules which would force such configuration tweaks to become necessary. We should reconsider the above rule and its consequence on the login issue Nick brought up. Regards, -Sandeep John Hufferd wrote: > > By the way, the OS is also suppose to have a way to hand out (partition up) > ISIDs to the various iSCSI Initiator functions, whether they are Software > or Hardware. > > So, even though, I was initially swayed by Nick's Arguments -- we require > the OS to partition up the ISID space and hand out specific ISIDs or ranges > of ISIDs (in some manor) to the iSCSI Initiator functions (regardless of > whether they are in Software or Hardware) -- I do not now see, if the > implementation is as specified in our spec., how there is a conflict in > ISID. > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com
Home Last updated: Tue Sep 11 01:17:22 2001 6499 messages in chronological order |