|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: response to second login (with same ISID)[The message I am replying to is below this one. A similar one was posted while I was composing this reply.] Santosh, If the iSCSI HBA is exposing SCSI targets to the OS, then the OS's SCSI target driver (or class driver if I have my Microsoft terminology correct) can support "exclusive access" semantics which can protect the current user of a tape device from other users on the same system attempting to use the same device through the same driver, or can allow a disk device (and the session for it) to be shared by multiple users when that is appropriate. If the target device supports some form of SCSI reserve/release, then this would protect the device from access via a second session from anywhere. In the target, iSCSI could also refuse a second concurrent session login to the same tape target protecting initiators which do not reserve/release. (The trick is: does the target think this is a new session using the same ISID (reject), or an attempt to clean-up and re-establish an existing session (reset, accept).) Think about an iSCSI enabled version of tar or cpio (simple applications used for tape backups). These could run from user space over a TCP connection on a standard NIC using an OS that has no awareness of iSCSI. If a second copy of the program is started, how is it to know that something is already using the same tape device? How is it to know the ISID used for that other copy? How is it to know whether ANY particular ISID is really currently in use, or what it is being used for? How can we prevent the second copy from unknowingly stealing the device from the first by simply using the same ISID? The second user thinks everything is fine until the first user restarts his command that just failed. In this model there is no HBA driver or target driver. There is nothing that knows about both sessions being attempted except the target. You may think this is a bit far fetched, but I almost have such a program. I expect other folks will be clever enough to think of other ways to use this "user mode access" capability of TCP/IP to use remote iSCSI devices without kernel co-operation. Can we enable them to peacefully co-exist with each other? Can they peacefully co-exist with kernel mode drivers? There may be other scenarios such as administrators dynamically adding and removing iSCSI devices to an OS while a system is running rather than at boot time (think 24x7 operations, what choice to they have?). If the ISID's are going to have to be manually configured, then there is a high likelihood of human error causing disruptions. If we can enable non-disruptive automatic ISID probing to find an available ISID during device configuration or initialization, this seems safer. Once we pick an ISID, we should still remember it across re-boot, to avoid repeated probing, and to assist manual clean-up after ungraceful shutdown. We also need the "logout this old session" capability both for recovery after an initiator crash or error which failed to logout, and for when the initiator realizes it has no remaining working TCP connections to an existing session and wants to be sure to free target resources and start fresh. So, I think there are valid arguments for both behaviors 1 and 2, and we need to enable the initiator to select the behavior appropriate for each application. Stated another way, we need to allow for the case when the initiator is sure that this ISID is unique and it takes full responsibility for all consequences, and for the case where the initiator can not be sure this ISID is unique and wants there to be no side effects for others if it turns out not to be unique. Thanks, Nick -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, May 23, 2001 8:36 PM To: Martin, Nick Cc: santoshr@cup.hp.com Subject: Re: iSCSI: response to second login (with same ISID) "Martin, Nick" wrote: > > I know from personal experience how easy it is for an authorized user to > unintentionally start a second copy of a backup program, while the tape > drive is still in use. This should be a harmless mistake. What kind of > traffic cop would prevent this request from making it to the iSCSI target > and terminating the session already in progress? (Rhetorical question, > please do not describe for me such a mechanism ;) Nick, I know you don't want an answer to your rhetorical question ;-}, but, I could'nt resist one quick query here. In the scenario you describe, is it not the case that HBA drivers would only send out a Login on the first open of that target, and on subsequent opens would only bump an open_count or a ref_count of some kind rather than send a login on the wire on every open ? If that is correct, then, the scenario you describe would still cause disruption even with the modified semantics, only, when the WRITE is issued by the 2nd execution of the backup application (?). Regards, Santosh
Home Last updated: Tue Sep 04 01:04:37 2001 6315 messages in chronological order |