On Sun, 2006-01-08 at 17:53 +0100, Arne Redlich wrote:
> Am Freitag, den 06.01.2006, 09:24 -0500 schrieb Ming Zhang:
> > I noticed that in discovery session, the cmd_sn is not updated and thus
> > some old NW iscsi ini feel unhappy about this. also the max_cmd_sn is
> > not update correctly as well.
> >
> >
> > Index: usr/iscsid.c
> > ===================================================================
> > --- usr/iscsid.c (revision 110)
> > +++ usr/iscsid.c (revision 111)
> > @@ -383,10 +383,9 @@
> > }
> >
> > ki->param_get(conn->tid, 0, conn->session_param);
> > - conn->exp_cmd_sn = be32_to_cpu(req->cmd_sn);
> > - log_debug(1, "exp_cmd_sn: %d,%d", conn->exp_cmd_sn,
> > req->cmd_sn);
> > - conn->max_cmd_sn = conn->exp_cmd_sn;
> > }
> > + conn->exp_cmd_sn = be32_to_cpu(req->cmd_sn);
> > + log_debug(1, "exp_cmd_sn: %d,%d", conn->exp_cmd_sn,
> > req->cmd_sn);
> > text_key_add(conn, "TargetPortalGroupTag", "1");
> > }
> >
> > @@ -570,6 +569,7 @@
> > rsp->sid = conn->sid;
> > rsp->stat_sn = cpu_to_be32(conn->stat_sn++);
> > rsp->exp_cmd_sn = cpu_to_be32(conn->exp_cmd_sn);
> > + conn->max_cmd_sn = conn->exp_cmd_sn;
> > rsp->max_cmd_sn = cpu_to_be32(conn->max_cmd_sn);
> > return;
> > init_err:
> > @@ -656,6 +656,7 @@
> >
> > rsp->stat_sn = cpu_to_be32(conn->stat_sn++);
> > rsp->exp_cmd_sn = cpu_to_be32(conn->exp_cmd_sn);
> > + conn->max_cmd_sn = conn->exp_cmd_sn;
> > rsp->max_cmd_sn = cpu_to_be32(conn->max_cmd_sn);
> > }
> >
> > @@ -674,6 +675,7 @@
> >
> > rsp->stat_sn = cpu_to_be32(conn->stat_sn++);
> > rsp->exp_cmd_sn = cpu_to_be32(conn->exp_cmd_sn);
> > + conn->max_cmd_sn = conn->exp_cmd_sn;
> > rsp->max_cmd_sn = cpu_to_be32(conn->max_cmd_sn);
> > }
> >
>
> Looks reasonable to me. I wonder why no other initiator has choked on
> it, yet?
my feeling is that they do not do strict check. if all check is done,
the performance can be low.
> Anyway, we should come to a conclusion concerning the AIX workaround, as
> this would require
> conn->max_cmd_sn = conn->exp_cmd_sn + trgt_param[key_queued_cmnds].val
think so.
> if we decide to merge it (actually this can be seen as one more reason
> not to merge the workaround :P).
>
> Arne
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
|
