SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: multiple initiator conflicting with target (was Re: iSCSI: response to second login (with same ISID)


    • To: ips@ece.cmu.edu
    • Subject: Re: iSCSI: multiple initiator conflicting with target (was Re: iSCSI: response to second login (with same ISID)
    • From: julian_satran@il.ibm.com
    • Date: Wed, 30 May 2001 01:00:48 +0300
    • Content-Disposition: inline
    • Content-type: text/plain; charset=us-ascii
    • Sender: owner-ips@ece.cmu.edu

    
    
    As far as I know this is a "primal" issue with all cooperating systems.
    SCSI has attempted to handle it with very granular reserve/release. However
    those where never very popular
    with vendors and users (except for exoteric systems block level
    reserve/release where not implemented) as they carry a high price tag and
    performance is quite low.  "Complicated software vendors" have fared
    slightly better
    as initiators that "cannot cooperate" can in fact and more effectively than
    targets - as they have a good handle on the lock semantics.
    
    However this is hardly an iSCSI issue and I suggest we take this off the
    IPS List.
    
    Julo
    
    "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <sbhagat@tripace.com> on 29-05-2001
    03:57:39
    
    Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)"
          <sbhagat@tripace.com>
    
    To:   "Patrick Stirling" <pms@veritas.com>
    cc:   "'Lakshmi Ramasubramanian'" <nramas@windows.microsoft.com>, "Santosh
          Rao" <santoshr@cup.hp.com>, ips@ece.cmu.edu
    Subject:  Re: iSCSI: multiple intiaitor conflicting with target (was Re:
          iSCSI: response to second login (with same ISID)
    
    
    
    
    Hello Patrick,
    
    Since the initiators are two different entities working completely
    independent of each other they cannot co-ordinate with each other. iSCSI
    Target also sees these two different initiators in different sessions as
    seperate entities. In the current implementation of iSCSI I guess it is not
    possible for two different initiators to know about each other and so it is
    difficult to resolve this conflicting situation.
    
    The answer to this problem might be lying in SAM-2 specifications. May be I
    am missing something there. Can somebody comment?
    
    Sanjeev
    
    >
    > On Mon, 28 May 2001, Sanjeev Bhagat (TRIPACE/Zoetermeer) wrote:
    >
    > > Well the conflict of writing to same sector can still be avoided by
    > > implementaion of some locks in the target but I wonder what will happen
    in
    > > this case where 2 inititators are connected to a target.
    >
    > > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com]
    > >
    > > Even if the target is capable of supporting multiple initiators, won't
    > > it cause problems  with devices such as disk - say, filesystem from the
    > > two initiators' side attempt to write
    > > to the same sectors (even not intentionally) would cause data
    > > corruption. Is iSCSI layer suppose to guard against this type of
    > > device sharing?
    >
    > Umm, am I missing something here?
    >
    > If 2 initiators want to access the same SCSI device, they must coordinate
    > to avoid clashing with each other. It's not the device's responsibility
    to
    > prevent this. This is one reason several companies have complicated
    > clustering software.
    >
    > patrick
    > Patrick Stirling
    > VERITAS Software (vendor of complicated clustering software!)
    >
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:35 2001
6315 messages in chronological order