SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Naming and Discovery



    Douglas Otis,
    Again, I think you have invented this need.  Yes there maybe new
    applications that may find a need to do what you said, but I am not sure
    that we need to worry about them, since they will be very few in number and
    can save what ever application information they need where ever they want
    to save it.
    
    The reason I say this, is because we are NOT building a NAS with a Shared
    File System on the Target, we are talking about "Raw" Volumes as seen by
    the various Hosts.  To make these things useable, you need, as a rule, to
    have a file system.  File systems, also as a rule, do not appreciate their
    Volumes coming and going.  They also do not share well with other File
    Systems.  (A little matter of locking and Meta data makes this difficult.)
    So the only real possibility here is for exactly the same File System on
    exactly the same homogeneous host to be started serially on various
    different systems, when they know the other systems have stopped and
    flushed all their caches, etc.  This is very unwieldy.  The other approach
    is, that they must have a share file system, and that is a big deal, and
    there are only a few in the world, and even fewer that might work across an
    internet connection.
    
    So based on the above, I for one, reject your "requirement" statement, as
    an unproven iSCSI need.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403
    Internet address: hufferd@us.ibm.com
    
    
    "Douglas Otis" <dotis@sanlight.net> on 10/09/2000 10:04:19 AM
    
    To:   John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI Naming and Discovery
    
    
    
    John,
    
    > Douglas Otis,
    > You said " ... You should consider the OS requirements for mounting.  The
    > database which defines the target:LUN:WWN should also include a name for
    > mounting...".
    >
    > I know of no such "Requirement".  So lets get back to the real
    > problems and
    > requirements.  I think the key point that we need to work on is the
    Naming
    > and Discovery of iSCSI Devices (Storage Controllers) in the Greater IP
    > network environment.
    
    In a normal drive environment, mounting information is rather static as is
    the interconnect to storage.  Providing such an extensible SAN, one should
    consider mounting dynamic drives.  In real life use, it would be extremely
    short sighted to ignore this *required* mounting information.  Rather than
    have the client store this information, the bootstrapping database can
    greatly assist the client by storing mounting information to assist in
    creating a suitable environment for running various applications.
    Eventually, tools should allow the user to redefine these values.
    
    LUN may be used at a higher level than the device.  As SCSI allows for this
    resolution, the naming scheme for mounting should also include this
    resolution.  Regardless in how a LUN is seen by the device, until such
    addressing is totally removed from SCSI, and I doubt it will be, providing
    needed structures for mounting based on user requirements should be
    considered within the bootstrapping database at the LUN level.  A symbolic
    means of organizing these drives is appropriate at this level of
    configuration even if the LUN may always have the value 0.
    
    Rather than burden transports with these details, acceptance of an external
    authentication scheme removes much of the burden this transport must bear.
    In the end, you will be developing an LDAP server within the transport
    protocol from the direction of this present scheme, otherwise.  DNS does
    not
    provide the needed selectors found with LDAP.
    
    Doug
    
    
    
    
    
    


Home

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