On Wed, 2006-01-11 at 10:48 -0800, K Chapman wrote:
> --- Ming Zhang <mingz@xxxxxxxxxxx> wrote:
>
> > On Wed, 2006-01-11 at 10:20 -0800, K Chapman wrote:
> > > --- Arne Redlich <arne.redlich@xxxxxxxxxxx> wrote:
> > >
> > > > As previously discussed, this is a slight
> > > > modification of Ming's CmdSN
> > > > patch. It fixes {Max,Exp}CmdSN values for
> > discovery
> > > > sessions and also
> > > > incorporates a workaround to the AIX CmdSN issue
> > by
> > > > incrementing
> > > > MaxCmdSN by 1.
> > > >
> > > > I hope it's alright to send this as one patch,
> > as
> > > > Ming's original patch
> > > > formatting was corrupted and the changes are
> > small
> > > > enough.
> > > >
> > > > @K Chapman
> > > > Could you please verify that the AIX issue is
> > fixed
> > > > by this patch? To do
> > > > so, please use svn rev. 21 and apply this one on
> > top
> > > > of it. Thanks.
> > > >
> > > > Arne
> > > >
> > > > Index: usr/iscsid.c
> > > >
> > >
> >
> ===================================================================
> > > > --- usr/iscsid.c (Revision 21)
> > > > +++ usr/iscsid.c (Arbeitskopie)
> > > > @@ -385,10 +385,9 @@
> > > > /* } */
> > > >
> > > > ki->param_get(conn->tid, 0, key_session,
> > > > 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");
> > > > }
> > > >
> > > > @@ -572,6 +571,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 + 1;
> > > > rsp->max_cmd_sn =
> > cpu_to_be32(conn->max_cmd_sn);
> > > > return;
> > > > init_err:
> > > > @@ -658,6 +658,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 + 1;
> > > > rsp->max_cmd_sn =
> > cpu_to_be32(conn->max_cmd_sn);
> > > > }
> > > >
> > > > @@ -676,6 +677,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 + 1;
> > > > rsp->max_cmd_sn =
> > cpu_to_be32(conn->max_cmd_sn);
> > > > }
> > >
> > > ok. with rev21 + cmdsn patch + event.c patch (and
> > > other back compat patches) + ISCSI_CONN_IOV_MAX
> > patch
> > > (to get 512k)
> >
> > could u skip that ISCSI_CONN_IOV_MAX patch and see
> > if works?
> >
> > >
> > > iet builds fine, and aix still works.
> >
> > as you know, what other OS/ini we should try? now we
> > handled hp-ux and
> > aix. windows is ok, nw works from report of list.
> > linux works.
>
> if i skip the ISCSI*MAX patch, the perf drops and i
> get warnings on iet.
so this is aix ini fault i think, it claims it can support MaxRxDSL
(this is its capability) while assume target accept this param means
target also has this capability. :P
is it possible for you to file a bug ticket to aix?
i know this is not follow the RFC, but can u try to specify that
parameter to 256K in your conf file, without that patch, and see if ok?
i think the patch has no harm to IET code, but might lead to OOM in low
HW configuration box.
>
> for other ini's, i have a list i use with iet, which
> is attached.
thx for sharing. seems we sweep almost all of them?
i think it is ok to roll out .4.13 now.
>
> aaarrrggghhh!!!!
> FreeBSD rocks
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> plain text document attachment (IET.txt), "3097556305-IET.txt"
> initiator vendor:OS disk discovery format/partition disk lvm use
> create fs issues ? CHAP cisco:solaris--> yes
> yes yes (note 6) yes no
> cisco:hp-ux11--> yes yes
> yes yes no cisco:aix-->
> yes yes yes yes no
> cisco:linux--> yes yes
> yes yes no freebsd:freebsd
> yes yes not tested yes
> no no openiscsi:linux--> yes yes
> yes yes no yes
> hp:hp-ux11i--> yes yes
> yes (note 3) yes no yes ibm:aix-->
> yes yes yes yes no
> (note 8) yes ms:windows xp/2k/2k3--> yes yes
> not tested yes no yes 1.
> encountered an error with IET with illegal operand. LVM did work, however
> import/export seemed to be problematic. more testing is required 2. read
> requests work fine, write requests seem to generate out of sequence errors on
> iet. the data still seems to be written ok. if you run iozone, the write perf
> may be poor due to this issue. 3. The Veritas Volume ManagerTM (VxVM) is not
> supported with the iSCSI Software Initiator Revision 11.11.03d 4. writes seem
> to cause issues. the true cause is unknown. 5. aix needed write_verify to
> create vg's. with no vg's everything else fails. 6. not tested with
> vxfs/vxvm. 7. unknown, doesnt work at all 8. aix benefits from an increase to
> ISCSI_CONN_IOV_MAX. NOTE: cisco ini's (the solaris ver for sure) have some
> odd effects on the target provider. i would suggest not using the cisco ini's
> if they can be avoided. in the case of solaris, there is no native ini for
> any ver less than 10 unless you have iscsi hba's which support < v10.
-------------------------------------------------------
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_idv37&alloc_id865&op=click
|
