|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI draft 02: logout
Look at 2b (yesterday) and there is an additional (tiny) change in 2c (not
out yet).
Regards,
Julo
Mark Bakke <mbakke@cisco.com> on 05/12/2000 00:30:10
Please respond to Mark Bakke <mbakke@cisco.com>
To: somesh gupta <someshg@yahoo.com>
cc: Matt Wakeley <matt_wakeley@agilent.com>, IPS Reflector
<ips@ece.cmu.edu>
Subject: Re: iSCSI draft 02: logout
Matt and Somesh-
I agree that a target should be allowed to do this. I would
agree with either a separate command or an addition to the
async_event. This would be extremely useful when rebooting a
target, or performing a manual shutdown, to ensure a smooth
failover.
I would add a second timer to the one specified by Somesh, and
have these determined by the target, and communicated as part of
the message. How about these:
1) Open time - the amount of time the connection will remain
available (e.g. the time until the reboot or shutdown occurs).
2) Wait time - the amount of time to wait after the reboot, before
attempting a new connection to the same address. This would
normally be the expected amount of time for the target to reboot,
or for the address to become available via a failover to another
unit.
After receiving this message, the initiator would stop sending
new commands, try to let any currently-executing commands finish,
and perform a normal connection logout. It would then wait for
(open time + wait time) before attempting a new connection.
I would expect these timers to normally be a few seconds each, but
perhaps milliseconds would be an appropriate unit measure.
--
Mark
somesh gupta wrote:
>
> --- Matt Wakeley <matt_wakeley@agilent.com> wrote:
> > Some comments on the logout command:
> >
> > - In Section 2.15, it indicates that the logout command is only used
> > for error
> > recovery. I thought there were those that wanted to always use the
> > logout to
> > close a connection cleanly.
> >
> > - One would think that a "logout" on the last TCP connection of a
> > session
> > would close the session. However, the error recovery steps in
> > section 4.1
> > seem to imply otherwise. If closing the last TCP connection of a
> > session does
> > not close the session, what does?
> >
> > - A target should be allowed to "logout" an initiator. This is
> > allowed in
> > fibre channel. It might be nice to have a reason code field
> > indicating why
> > the logout was performed.
>
> I had proposed (in a coversation with Julain in Pittsburg) a
> logout_requested command which the target could send to the initiator,
> and the target -- after waiting for some time (the target determines
> it)
> could then terminate/close any still open connections.
>
> This feature would avoid entering recovery states (which in my
> experience aren't implemented/tested thoroughly) in cases where e.g.
> a controller board on a multi-controller array was to be serviced.
>
> Initiators could divert all their traffic to other ports without having
> to go through session and command recovery.
>
> Somesh
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054
Home Last updated: Tue Sep 04 01:06:12 2001 6315 messages in chronological order |