SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Review of the 07 draft



    Actually, when I said SCSI Utility, I meant generic SCSI Utilities that
    don't know or care about the transport. There are some things that are
    "duals" in the various transports and have meaning to a generic SCSI
    Utilities.
    
    If, for example, a user wants to try fiddling with EMPD, he should not have
    to use an iSCSI utility ... he should be able to use a generic utility.
    
    Eddy
    ----- Original Message -----
    From: "Robert Griswold" <rgriswold@crossroads.com>
    To: <deva@stargateip.com>; "Eddy Quicksall" <ESQuicksall@hotmail.com>; "Jim
    Hafner" <hafner@almaden.ibm.com>
    Cc: <ips@ece.cmu.edu>
    Sent: Friday, August 10, 2001 9:25 AM
    Subject: RE: Review of the 07 draft
    
    
    Deva:
    
    I would argue that having two ways to change the same thing adds
    flexibility, rather than complexity.  If the iSCSI Text Messages are
    allowed to change iSCSI only parameters, then the transport has access
    to what it needs.  In addition, if the SCSI utility is aware of iSCSI
    mode pages (which of course it would need to be to even understand
    accessing iSCSI pages), then only one interface is needed for all
    aspects of the target.  As stated by Eddy, the legacy of SCSI is that
    mode pages, irrespective of what those parameters are manipulating
    (transport, commands, responses, timing, etc.), are accessible through
    SCSI mode commands.
    
    If mode page changes were not allowed to modify existing communication
    parameters (for existing connections), then there is no problem.  Once
    all active connections were dropped, then the re-establishment of
    connections would present new defaults for critical iSCSI or SCSI
    parameters.  Does this sound reasonable?
    
    Bob
    
    Robert Griswold
    Technologist
    Crossroads Systems, Inc.
    512-928-7272
    
     -----Original Message-----
    From: Dev [mailto:deva@stargateip.com]
    Sent: Thursday, August 09, 2001 7:33 PM
    To: Robert Griswold; Eddy Quicksall; Jim Hafner
    Cc: ips@ece.cmu.edu
    Subject: RE: Review of the 07 draft
    
    All,
    
    I tend to disagree. The parameters for the iSCSI are negotiated between
    the
    initiator and target.
    If we allow the parameters to be changed through SCSI Mode select, how
    will
    this work?
    
    If parameters can be changed through SCSI Mode select then it will apply
    only to Lead only connections.
    
    So, we'll have
    
    a) two methods to change the Lead only parameters common for the entire
    session (one through mode select
    and the other through text parameters)
    b) Just iSCSI text command to change the connection specific parameters.
    
    Does it not add to complexity having multiple ways to change the same
    stuff?
    
    Thanks
    
    Deva
    Platys communications
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Robert Griswold
    Sent: Thursday, August 09, 2001 1:36 PM
    To: Eddy Quicksall; Jim Hafner
    Cc: ips@ece.cmu.edu
    Subject: RE: Review of the 07 draft
    
    
    Eddy:
    
    I actually have no problem with all mode pages (SCSI and iSCSI) being
    accessible and changeable from standard SCSI mode commands.  My initial
    response to this section was to propose a method that would be
    acceptable to the authors of the iSCSI draft.  If there is desire in the
    group to allow mode pages for the entire target to be manipulated from
    the SCSI level, I think that is a better idea that the one I proposed.
    I would assume that an iSCSI aware SCSI utility would understand the
    iSCSI specific settings, and allow the user to make those changes.  What
    I am really against, is the ability to modify standard SCSI mode page
    settings from text messages, as that could lead to target behavior
    changes outside of the understanding of the SCSI nexus.
    
    To recap your thinking:  Allow iSCSI text messages to modify and read
    iSCSI only mode settings (potentially allowing the reading if SCSI mode
    settings), but allow SCSI mode commands to modify and read all target
    mode settings, including iSCSI settings.  Is that what you are saying.
    If so, I agree.
    
    Bob
    
    Robert Griswold
    Technologist
    Crossroads Systems, Inc.
    512-928-7272
    
     -----Original Message-----
    From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
    Sent: Thursday, August 09, 2001 2:08 PM
    To: Robert Griswold; Jim Hafner
    Cc: ips@ece.cmu.edu
    Subject: Re: Review of the 07 draft
    
    I don't like the idea of not letting a user of a SCSI utility be able to
    change some of the parameters for iSCSI. Because they may be relevant to
    him
    and there may not be a user interface to the iSCSI driver. pSCSI sets
    these
    low level parameters via a standard mode set, so why not iSCSI?
    
    It would be best if we could work out something where only the SCSI
    layer
    can set the mode pages. That would solve everything.
    
    Eddy
    
    ----- Original Message -----
    From: "Jim Hafner" <hafner@almaden.ibm.com>
    To: "Robert Griswold" <rgriswold@Crossroads.com>
    Cc: <ips@ece.cmu.edu>
    Sent: Friday, August 03, 2001 5:26 PM
    Subject: Re: Review of the 07 draft
    
    > Well, in fact, the draft is supposed to say that MODE_SELECT for the
    > transport-specific mode page will NOT be done via SCSI, only via Text
    > commands.  I read that as saying that from the SCSI layer, all fields
    in
    > these pages are "unchangeable" (even though they can change in the
    iSCSI
    > layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
    > CHANGED unit attentions get thrown up at the SCSI layer when this
    happens
    > at the iSCSI layer.... You later have a clarifying question (Section
    3) on
    > this as well.
    >
    > Regards,
    > Jim Hafner
    >
    >
    >
    >
    
    
    
    
    
    


Home

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