SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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