From ips-bounces@ietf.org Thu Nov 01 08:40:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZKi-0005qU-40; Thu, 01 Nov 2007 08:39:36 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1InZKg-0005nO-Ru for ips-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 08:39:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZKg-0005iY-60 for ips@ietf.org; Thu, 01 Nov 2007 08:39:34 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InZKZ-0007qO-P4 for ips@ietf.org; Thu, 01 Nov 2007 08:39:28 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lA1CdR4e008239 for ; Thu, 1 Nov 2007 08:39:27 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lA1CdBgr007614 for ; Thu, 1 Nov 2007 08:39:25 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 08:39:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2007 08:39:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFCs 5046/7/8 and the IPS WG Thread-Index: AcgchCDOANYgHLzNSueNOKACDq68wA== X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 01 Nov 2007 12:39:03.0681 (UTC) FILETIME=[2F6A3710:01C81C84] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Black_David@emc.com Subject: [Ips] RFCs 5046/7/8 and the IPS WG X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Everyone, With the publication of RFCs 5046, 5047 and 5048, the program of work of the IPS Working Group has been completed. I would like to thank all the authors and WG members for their hard work and support - we have produced 25 RFCs for iSCSI, FCIP, iFCP and related protocols, and the results of our work are in widespread daily use. This has been an adventure, and it's been my privilege to serve as one of the chairs of this WG; I'd like to specifically thank Elizabeth Rodriguez and Steve Bellovin for their past service as co-chairs. There will be an announcement shortly that the IPS Working Group is being closed because it has finished its program of work. The ips@ietf.org mailing list will remain open and active - this is still a fine place to send questions about our protocols and to organize work efforts (including soliciting volunteers) to produce any updates to our protocols that may be desired in the future. Congratulations to all and many thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 02 13:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io0kc-0005aT-I6; Fri, 02 Nov 2007 13:56:10 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Io0kb-0005Zu-MA for ips-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 13:56:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io0kb-0005G2-Ay for ips@ietf.org; Fri, 02 Nov 2007 13:56:09 -0400 Received: from mail.ttlc.net ([66.94.32.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io0k2-0007nE-8M for ips@ietf.org; Fri, 02 Nov 2007 13:55:35 -0400 Received: from bbrdv9000 [70.90.99.65] by mail.ttlc.net with ESMTP (SMTPD-9.21) id A48B1374; Fri, 02 Nov 2007 13:55:23 -0400 From: "Barry Reinhold" To: Date: Fri, 2 Nov 2007 13:54:56 -0400 Organization: Lamprey Networks Message-ID: <00b301c81d79$7cd325c0$76797140$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgdeXpCxVkq76RURFip8AiPVA1DxA== Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Subject: [Ips] Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bbr@lampreynetworks.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966298281==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0966298281== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01C81D57.F5C185C0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_00B4_01C81D57.F5C185C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question relative to the proper understanding of the following conformance statement from 3.2.2.1 A numbered iSCSI request will not change its allocated CmdSN, regardless of the number of times and circumstances in which it is reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is only relevant when the command has not created any state related to its execution (execution state); afterwards, CmdSN becomes irrelevant. Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. If no execution state is found, it is followed by ordering and delivery. If an execution state is found, it is followed by delivery. Is the proper understanding of this requirement imply that if a task w/ ITT=100, sent in an iSCSI PDU w/ CmdSN = 10, has been submitted to the device server and is "executing", that if another command with the same ITT and a CmdSN = 12 (no CmdSN 11 has been xmitted) is received by the target, it should ignore the CmdSN = 12 and submit the command to the device server? So, I could send a Task Management command using the proper ITT (without the immediate bit set) using an out of order CmdSN and the device server would process the command, resulting in a response w/ a status? Barry Reinhold (603) 868-8411 bbr@lampreynetworks.com ------=_NextPart_000_00B4_01C81D57.F5C185C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Question relative to the proper understanding of = the following conformance statement from 3.2.2.1

 

A numbered iSCSI request will not change its = allocated CmdSN,

regardless of the number of times and circumstances = in which it is

reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is

only relevant when the command has not created any = state related to

its execution (execution state); afterwards, CmdSN = becomes

irrelevant. Testing for the execution state = (represented by

identifying the Initiator Task Tag) MUST precede = any other action at

the target. If no execution state is found, it is = followed by

ordering and delivery. If an execution state is = found, it is

followed by delivery.

 

Is the proper understanding of this requirement imply that if a task w/ = ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has been submitted to the device = server and is “executing”, that if another command with the same ITT = and a CmdSN =3D 12 (no CmdSN 11 has been xmitted) is received by the target, = it should ignore the CmdSN =3D 12 and submit the command to the device = server?

 

So, I could send a Task Management command using the proper ITT (without the immediate bit set) using an out of order CmdSN and the device server = would process the command, resulting in a response w/ a = status?

 

 

Barry Reinhold

(603) 868-8411

bbr@lampreynetworks.com=

 

------=_NextPart_000_00B4_01C81D57.F5C185C0-- --===============0966298281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0966298281==-- From ips-bounces@ietf.org Fri Nov 02 14:31:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io1Iu-0003Bt-Vp; Fri, 02 Nov 2007 14:31:36 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Io1It-0003B0-S0 for ips-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 14:31:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io1It-0003AT-FZ for ips@ietf.org; Fri, 02 Nov 2007 14:31:35 -0400 Received: from smtpoutm.mac.com ([17.148.16.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io1Is-00013M-MQ for ips@ietf.org; Fri, 02 Nov 2007 14:31:35 -0400 Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id lA2IVXSp002295; Fri, 2 Nov 2007 11:31:33 -0700 (PDT) Received: from [17.151.104.124] ([17.151.104.124]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id lA2IVSRI025809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Nov 2007 11:31:30 -0700 (PDT) Message-Id: <87CF0E62-F9D0-4CC6-A857-D4B57B057663@mac.com> From: William Studenmund To: bbr@lampreynetworks.com In-Reply-To: <00b301c81d79$7cd325c0$76797140$@com> Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [Ips] Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. Date: Fri, 2 Nov 2007 11:31:20 -0700 References: <00b301c81d79$7cd325c0$76797140$@com> X-Mailer: Apple Mail (2.912) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0466430951==" Errors-To: ips-bounces@ietf.org --===============0466430951== Content-Type: multipart/alternative; boundary=Apple-Mail-15-972715795 --Apple-Mail-15-972715795 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 2, 2007, at 10:54 AM, Barry Reinhold wrote: > Question relative to the proper understanding of the following =20 > conformance statement from 3.2.2.1 > > A numbered iSCSI request will not change its allocated CmdSN, > regardless of the number of times and circumstances in which it is > reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is > only relevant when the command has not created any state related to > its execution (execution state); afterwards, CmdSN becomes > irrelevant. Testing for the execution state (represented by > identifying the Initiator Task Tag) MUST precede any other action at > the target. If no execution state is found, it is followed by > ordering and delivery. If an execution state is found, it is > followed by delivery. > > Is the proper understanding of this requirement imply that if a task =20= > w/ ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has been submitted = =20 > to the device server and is =93executing=94, that if another command =20= > with the same ITT and a CmdSN =3D 12 (no CmdSN 11 has been xmitted) is = =20 > received by the target, it should ignore the CmdSN =3D 12 and submit =20= > the command to the device server? What kind of second packet are you talking about? Your question above =20= is very vague. > So, I could send a Task Management command using the proper ITT =20 > (without the immediate bit set) using an out of order CmdSN and the =20= > device server would process the command, resulting in a response w/ =20= > a status? I believe you are correct. Take care, Bill= --Apple-Mail-15-972715795 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Nov 2, 2007, at = 10:54 AM, Barry Reinhold wrote:

Question relative to the = proper understanding of the following conformance statement from = 3.2.2.1
 
A = numbered iSCSI request will not change its allocated = CmdSN,
regardless of the number of times and = circumstances in which it is
only relevant when the command has not created = any state related to
its execution = (execution state); afterwards, CmdSN becomes
identifying the Initiator Task Tag) MUST precede = any other action at
the target. If no = execution state is found, it is followed by
followed by = delivery.
 
Is the proper understanding of this requirement imply = that if a task w/ ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has = been submitted to the device server and is =93executing=94, that if = another command with the same ITT and a CmdSN =3D 12 (no CmdSN 11 has = been xmitted) is received by the target, it should ignore the CmdSN =3D = 12 and submit the command to the device = server?

What kind of second packet = are you talking about? Your question above is very vague.

So, I could send a Task = Management command using the proper ITT (without the immediate bit set) = using an out of order CmdSN and the device server would process the = command, resulting in a response w/ a = status?

I = believe you are correct.

Take care,

Bill
= --Apple-Mail-15-972715795-- --===============0466430951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0466430951==-- From ips-bounces@ietf.org Fri Nov 02 16:33:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3AN-0002bg-GG; Fri, 02 Nov 2007 16:30:55 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Io3AM-0002ax-Dg for ips-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 16:30:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3AM-0002Y4-2E for ips@ietf.org; Fri, 02 Nov 2007 16:30:54 -0400 Received: from noteserv1.attotech.com ([208.69.85.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io3AE-00065A-N7 for ips@ietf.org; Fri, 02 Nov 2007 16:30:46 -0400 In-Reply-To: <87CF0E62-F9D0-4CC6-A857-D4B57B057663@mac.com> To: bbr@lampreynetworks.com Subject: Re: [Ips] Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: dcuddihy@attotech.com Date: Fri, 2 Nov 2007 16:30:45 -0400 X-MIMETrack: Serialize by Router on NOTESERV1/SERV/ATTO(Release 7.0.2FP1|January 10, 2007) at 11/02/2007 04:30:46 PM, Serialize complete at 11/02/2007 04:30:46 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0837217502==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0837217502== Content-Type: multipart/alternative; boundary="=_alternative 0070ADD485257387_=" This is a multipart message in MIME format. --=_alternative 0070ADD485257387_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Barry, So, I could send a Task Management command using the proper ITT=20 (without the immediate bit set) using an out of order CmdSN and the device server would process the command, resulting in a=20 response w/ a status? I'm not sure what the 'proper ITT' means. In my understanding, each Task = Mangement command has a unique ITT. The ITT of the currently active=20 command (to be aborted or reassigned) is in the Referenced Task Tag field. = The unique ITT in the task management command will not have any execution = state, and thus will be subject to ordering.=20 regards, david Java: The elegant simplicity of C++=20 and the blazing speed of smalltalk. David J Cuddihy Principal Engineer ATTO Technology, Inc. =20 www.attotech.com Power Behind the Storage William Studenmund =20 11/02/2007 02:40 PM To bbr@lampreynetworks.com cc ips@ietf.org Subject Re: [Ips] Testing for the execution state (represented by identifying the=20 Initiator Task Tag) MUST precede any other action at the target. On Nov 2, 2007, at 10:54 AM, Barry Reinhold wrote: Question relative to the proper understanding of the following conformance = statement from 3.2.2.1 =20 A numbered iSCSI request will not change its allocated CmdSN, regardless of the number of times and circumstances in which it is reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is only relevant when the command has not created any state related to its execution (execution state); afterwards, CmdSN becomes irrelevant. Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. If no execution state is found, it is followed by ordering and delivery. If an execution state is found, it is followed by delivery. =20 Is the proper understanding of this requirement imply that if a task w/=20 ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has been submitted to the = device server and is ?executing?, that if another command with the same=20 ITT and a CmdSN =3D 12 (no CmdSN 11 has been xmitted) is received by the=20 target, it should ignore the CmdSN =3D 12 and submit the command to the=20 device server? What kind of second packet are you talking about? Your question above is=20 very vague. So, I could send a Task Management command using the proper ITT (without=20 the immediate bit set) using an out of order CmdSN and the device server=20 would process the command, resulting in a response w/ a status? I believe you are correct. Take care, Bill=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0070ADD485257387_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Barry,

        So, I could send a Task Management command using the proper ITT (without the immediate bit set) using an out of order CmdSN
        and the device server would process the command, resulting in a response w/ a status?

I'm not sure what the 'proper ITT' m= eans.   In my understanding, each Task Mangement command has a unique ITT.  The ITT of the currently active command (to be aborted or reassigned) is in the Referenced Task Tag field.  The unique ITT in the task manag= ement command will not have any execution state, and thus will be subject to ordering.  

regards,

david


Java: The elegant simplicity of C++
and the blazing speed of smalltalk.

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.


www.attotech.com
Power Behind the Storage


William Studenmund &l= t;wrstuden@mac.com>

11/02/2007 02:40 PM

To
bbr@lampreynetworks.com
cc
ips@ietf.org
Subject
Re: [Ips] Testing for the execution state (represented by        identifying        the Initiator Task Tag) MUST precede any other        action at the target.





On Nov 2, 2007, at 10:54 AM, Barry Reinhold wrote:

Question relative to the proper underst= anding of the following conformance statement from 3.2.2.1
 
A numbered iSCSI request will not change its allocated CmdSN,
regardless of the number of times and c= ircumstances in which it is
reissued (see Section 6.2.1 Usage of Re= try). At the target, CmdSN is
only relevant when the command has not created any state related to
its execution (execution state); afterw= ards, CmdSN becomes
irrelevant. Testing for the execution s= tate (represented by
identifying the Initiator Task Tag) MUST precede any other action at
the target. If no execution state is fo= und, it is followed by
ordering and delivery. If an execution state is found, it is
followed by delivery.
 
Is the proper understanding of this requirement imply that if a task w/ ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has been submitted to the device server and is “exec= uting”, that if another command with the same ITT and a CmdSN =3D 12 (no CmdSN 11 has been xmitted) is received by the target, it should ignore the CmdSN =3D 12 and submit the command to the device server?

What kind of second packet are you talking about? Your question above is very vague.

So, I could send a Task Managem= ent command using the proper ITT (without the immediate bit set) using an out of order CmdSN and the device server would process the command, resulting in a response w/ a status?

I believe you are correct.

Take care,

Bill=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0070ADD485257387_=-- --===============0837217502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0837217502==-- From ips-bounces@ietf.org Fri Nov 02 17:36:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4Aj-0002lB-IX; Fri, 02 Nov 2007 17:35:21 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Io4Ai-0002jZ-81 for ips-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 17:35:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4Ah-0002jO-SA for ips@ietf.org; Fri, 02 Nov 2007 17:35:19 -0400 Received: from smtpoutm.mac.com ([17.148.16.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io4Ah-0002QW-0R for ips@ietf.org; Fri, 02 Nov 2007 17:35:19 -0400 Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout019/MantshX 4.0) with ESMTP id lA2LZIai003203; Fri, 2 Nov 2007 14:35:18 -0700 (PDT) Received: from [17.151.104.124] ([17.151.104.124]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id lA2LZFJd001131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Nov 2007 14:35:16 -0700 (PDT) Message-Id: <279F93BA-CE1C-4341-94E2-5ECB930EDDDA@mac.com> From: William Studenmund To: Ips In-Reply-To: <87CF0E62-F9D0-4CC6-A857-D4B57B057663@mac.com> Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [Ips] Testing for the execution state (represented by identifying the Initiator Task Tag) MUST precede any other action at the target. Date: Fri, 2 Nov 2007 14:35:05 -0700 References: <00b301c81d79$7cd325c0$76797140$@com> <87CF0E62-F9D0-4CC6-A857-D4B57B057663@mac.com> X-Mailer: Apple Mail (2.912) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: bbr@lampreynetworks.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1753995638==" Errors-To: ips-bounces@ietf.org --===============1753995638== Content-Type: multipart/alternative; boundary=Apple-Mail-16-983741003 --Apple-Mail-16-983741003 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 2, 2007, at 11:31 AM, William Studenmund wrote: > On Nov 2, 2007, at 10:54 AM, Barry Reinhold wrote: > >> Question relative to the proper understanding of the following =20 >> conformance statement from 3.2.2.1 >> >> A numbered iSCSI request will not change its allocated CmdSN, >> regardless of the number of times and circumstances in which it is >> reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is >> only relevant when the command has not created any state related to >> its execution (execution state); afterwards, CmdSN becomes >> irrelevant. Testing for the execution state (represented by >> identifying the Initiator Task Tag) MUST precede any other action at >> the target. If no execution state is found, it is followed by >> ordering and delivery. If an execution state is found, it is >> followed by delivery. >> >> Is the proper understanding of this requirement imply that if a =20 >> task w/ ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has been =20 >> submitted to the device server and is =93executing=94, that if = another =20 >> command with the same ITT and a CmdSN =3D 12 (no CmdSN 11 has been =20= >> xmitted) is received by the target, it should ignore the CmdSN =3D 12 = =20 >> and submit the command to the device server? > > What kind of second packet are you talking about? Your question =20 > above is very vague. > >> So, I could send a Task Management command using the proper ITT =20 >> (without the immediate bit set) using an out of order CmdSN and the =20= >> device server would process the command, resulting in a response w/ =20= >> a status? > > I believe you are correct. Having re-read the TMReq documentation, I take the above back. :-) The TMReq for an abort will have its own ITT, different from that of =20 the task it is aborting. So using the ITT of the command you want to =20 abort is flat-out wrong. My understanding of the text way above regarding CmdSN is that it =20 really matters for linked commands. So for a Linked command, a =20 subsequent command request doesn't have to wait for CmdSN processing =20 before it gets handed down to the existing task. Take care, Bill= --Apple-Mail-16-983741003 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Nov 2, 2007, at = 11:31 AM, William Studenmund wrote:

On Nov 2, 2007, at = 10:54 AM, Barry Reinhold wrote:

Question relative to the = proper understanding of the following conformance statement from = 3.2.2.1
 
A = numbered iSCSI request will not change its allocated = CmdSN,
regardless of the number of times and = circumstances in which it is
only relevant when the command has not created = any state related to
its execution = (execution state); afterwards, CmdSN becomes
identifying the Initiator Task Tag) MUST precede = any other action at
the target. If no = execution state is found, it is followed by
followed by = delivery.
 
Is the proper understanding of this requirement imply = that if a task w/ ITT=3D100, sent in an iSCSI PDU w/ CmdSN =3D 10, has = been submitted to the device server and is =93executing=94, that if = another command with the same ITT and a CmdSN =3D 12 (no CmdSN 11 has = been xmitted) is received by the target, it should ignore the CmdSN =3D = 12 and submit the command to the device = server?

What kind of second packet = are you talking about? Your question above is very vague.

So, I could send a Task = Management command using the proper ITT (without the immediate bit set) = using an out of order CmdSN and the device server would process the = command, resulting in a response w/ a = status?

I = believe you are correct.

Having = re-read the TMReq documentation, I take the above back. = :-)

The = TMReq for an abort will have its own ITT, different from that of the = task it is aborting. So using the ITT of the command you want to abort = is flat-out wrong.

My understanding of the = text way above regarding CmdSN is that it really matters for linked = commands. So for a Linked command, a subsequent command request doesn't = have to wait for CmdSN processing before it gets handed down to the = existing task.

Take care,

Bill
= --Apple-Mail-16-983741003-- --===============1753995638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1753995638==-- From ips-bounces@ietf.org Thu Nov 15 15:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslL1-0003X5-Qd; Thu, 15 Nov 2007 15:29:23 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IslL0-0003WG-B0 for ips-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 15:29:22 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IslL0-0003W4-1N for ips@ietf.org; Thu, 15 Nov 2007 15:29:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslHY-0006c9-DY for ips@ietf.org; Thu, 15 Nov 2007 15:25:48 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IslHX-0006kX-KX for ips@ietf.org; Thu, 15 Nov 2007 15:25:48 -0500 Received: (qmail 5343 invoked from network); 15 Nov 2007 20:25:46 -0000 Received: from unknown (HELO ?192.168.0.116?) (nicholas_bellinger@sbcglobal.net@70.132.10.247 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 15 Nov 2007 20:25:46 -0000 X-YMail-OSG: 1hE4pk4VM1lL3prepxwYagZH7b3RkHcxgG4HdcDMwdC3n4wkgf6Yt7mSMSE4W15vd6bBbKK_pUStRKI.mx1EMctP From: "Nicholas A. Bellinger" To: LKML , linux-scsi , "Linux-iSCSI.org Target Dev" , Open iSCSI , Mike Christie , FUJITA Tomonori , Ming Zhang , Robert Whitehead , Matthew Wilcox , "H. Peter Anvin" , Christoph Hellwig , James Bottomley , Andrew Morton , Mike Mazarick , Mike Young , iet-dev , ips reflector Content-Type: text/plain Date: Thu, 15 Nov 2007 12:25:44 -0800 Message-Id: <1195158344.4834.62.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-TMDA-Confirmed: Thu, 15 Nov 2007 15:29:22 -0500 Cc: nab@kernel.org Subject: [Ips] [ANNOUNCE] - Linux-iSCSI.org Storage Engine goes online! X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Greetings all, It is my great pleasure to announce that the Linux-iSCSI.org project has reached its first 2.9-BETA release and its now offering the ability to build source against any RPM or DEB based kernel and distribution. The Linux-iSCSI.org West cluster is offering binaries for CentOS 5 and Debian 4, and instructions are now online. This project provides the infrastructure pieces required to run a production IP storage fabric, and is constantly evolving. The complete target stack, which is now available in source and binary form @ Linux-iSCSI.org, allows the storage admin to combine virtualization technologies (Xen, HVM, VMware), cluster filesystems (OCFS2, GFS) and Linux kernel storage functionality (DM, LVM, MD) for your very own IP storage cluster. This IP storage cluster has been up and running at Linux-iSCSI.org, and the guests are able to build their packages on top of Linux OCFS2, and making iSCSI cluster storage available for download at http://linux-iscsi.org/builds/ All together, the cluster has 16 GB of memory and 16x x86_64 cores with cpuspeed lowering the clocks to 1Ghz where availabile. There are total of 10 virtual machines (6 paravirtualizated + 4 HVM) running iSCSI storage between the two machines running the Target. A handful of these are currently in production using IPv4 and TCP and providing services to Linux-iSCSI.org West. On target storage is being exported via LVM block devices on top of a software RAID6 SATA software on RHEL v4u5 using Linux-iSCSI.org on v2.9 on CentOS v4. The storage objects are cut into 100 GB volumes and imported into the target stack and the ports created to storage object and portal group endpoints. From there the iSCSI endpoints are exported to hosts and guests across a mixed-mode 1 and 10 Gb/sec networking fabric. IPv6 and SCTP support has also been included in current target module builds, and moving the project's fabric to IPv6 is planned in the near future. Also, a little bit about the origins of the target stack, which is known throughout the industry as the "PyX" stack. The software, which has been on constant development since the fall of 2001, has been behind number 'worlds first' developments in the IP storage space, including a 10 Gb/sec throughput worlds record in Early 2005. The target stack was developed in parallel with an iSCSI initiator stack, known as Core-ISCSI. Recently, I have purchased the exclusive rights to the software, and as the principle developer, have released the source code under the GPL license. The code is currently running the production services for the Linux-iSCSI.org West cluster, and the project looking for interested developers, admins, users and vendors. As the implementation possibilities for IP storage are virtually limitless, the goal of the project is to offer not just the software to install and configure the environment, but the knowledge to create, grow, reproduce, and maintain a complete open source IP storage fabric. While it is possible today for those with the know-how and the time to put these open source pieces together, there is a great opportunity to benefit for not just developers, but end users, admins, and vendors who are interested in what open source IP storage on Linux can do for them. There much interest with Linux-iSCSI and virtulization technologies lately, and I am happy to report that the first Linux-iSCSI.org target running in guest mode has successfully exported locally attached disks and optical drives, on both Linux and non-Linux hosts using VMware Workstation 6. As this will be surely be one of the popular uses of Linux-iSCSI.org, and I am starting to collect the information for a howto and eventually downloadable system images. Please stay tuned for this. :-) While we have reached milestones at Linux-iSCSI.org recently, there is still much work to be done. Both in terms of the code, the documentation, and the UI. For the Target code that is in production, I am working on a ncurses based shell for typical types of functionality. As the interest starts to grow, this is going to be key piece of reducing the learning curve for working with the Linux/iSCSI code. Also, the plan is to put the kernel code into a git tree on kernel.org to determine which pieces should be headed toward the kernel. While I am sure there will be much debate about this subject, the immediate goal has been to offer a production quality stack in the near term so that kernel devs can have the time to get the code fragments ready, without a large and hungry user community that is looking for useable code, and not code persay that is still having bugs worked out. While there are many iSCSI projects in the Linux universe, my hope is that we as a community can come together in order to take advantage of the tremendous amount of talent eager to learn. There is also so much excellent code available, that I hope we as developers can focus on taking the best parts of each project and putting them together to create the highest quality open source storage stack on the available today. --nab _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Nov 30 09:56:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7Hq-0001BO-AH; Fri, 30 Nov 2007 09:56:14 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Iy7Hp-0001BB-Ou for ips-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 09:56:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7Hp-0001Ap-F5 for ips@ietf.org; Fri, 30 Nov 2007 09:56:13 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iy7Hn-0007Lf-QL for ips@ietf.org; Fri, 30 Nov 2007 09:56:13 -0500 Received: (qmail 59372 invoked from network); 30 Nov 2007 14:56:11 -0000 Received: from unknown (HELO ?192.168.0.117?) (nicholas_bellinger@sbcglobal.net@70.231.235.216 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2007 14:56:10 -0000 X-YMail-OSG: 2j.EyjYVM1ltYmyq6Tj9rEP3iqYL1BNKbGZ307dd5TLddiJot3rl_MKRiZvD2IpG.KNTY7aBmaMrnpgLVOf5rzsdkD0KXYrySl1zYd.eKobJ5PJ8aw-- From: "Nicholas A. Bellinger" To: "Linux-iSCSI.org Target Dev" Date: Fri, 30 Nov 2007 06:55:59 -0800 Message-Id: <1196434559.7468.18.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Andrew Morton , James Bottomley , Mike Christie , linux-scsi , iet-dev , Michael Brown , Mike Mazarick , LKML , "Ross S. W. Walker" , FUJITA Tomonori , Matthew Wilcox , Mike Young , "H. Peter Anvin" , ips reflector , Open iSCSI , Robert Whitehead , Christoph Hellwig Subject: [Ips] LIO-VM Demo Images available for download! X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0742105643==" Errors-To: ips-bounces@ietf.org --===============0742105643== Content-Type: multipart/alternative; boundary="=-8hnWZBlOBQ9Pwg5977DM" --=-8hnWZBlOBQ9Pwg5977DM Content-Type: text/plain Content-Transfer-Encoding: 7bit Grettings all, It is my great honor to announce that the LIO-VM Target images are now online and available for download: http://linux-iscsi.org/builds/LIO-VM/vmware/ and the wiki entry (which is basically the README now) is also online: http://linux-iscsi.org/index.php/LIO-VM Please check the wiki for the complete release information. Here are the bullets from the README. Have Fun!!! :-) --nab ---------------------------------------------------------------------------------------------------------------------------------- Introduction: The LIO-VM Storage Engine demo is a set of VMware compatible virtual machine images that contains a self-configuring iSCSI storage engine that runs on with a very large and diverse amount of PC storage software and hardware. When the LIO-VM image boots, the host local storage hardware that is made available to the guest is exported as iSCSI target ports, and made available to both local and remote iSCSI Initiator clients. Note that the iSCSI target is configured to allow _ALL_ iSCSI Initiators to access _ALL_ iSCSI Target Ports across all available iSCSI Network Portals. By default, the storage devices with filesystems will be exported as READ-ONLY to prevent multiple accesses by non-cluster filesystems. Support for production R/W configurations of this demo are in the works, please stay tuned to the site and lists for more information as this unfolds. Also, if you really know what you are doing when it comes to non cluster filesystem + RW access, please see section IX) below. I) The .vmx LIO-VM images: There are two VMware Workstation 6.x/Fusion compatible image available: Debian Etch 4 i386: (2.6.18-5-686) JeOS / Ubuntu 7.10 i386: (2.6.22-14-virtual) II) What are the host OS requirements to run the LIO-VM Demo? Any i386 or x86_64 Linux v2.6 host that can run VMware Workstation 6. Any Apple Mac-tel hardware that can run VMware Fusion. Any XP or NT compatible host that can run VMware Workstation 6. III) What has been tested? The LIO-VM has been successfully run on Linux v2.6, MacOSX Leopard, and WinXP/NT. USB connected flash and SATA/PATA devices. Internal SATA DVD and External SATA HD drives External USB DVD/HD devices are also supported. IV) What should work? All USB Direct-Access (flash, USB external PATA/SATA disk drives) All USB optical drives (CD, DVD, HD/DVD and BD) All PATA/SATA disk drives All PATA/SATA optical drives (CD, DVD, HD/DVD and BD) All PSCSI / FC / SAS hardware with correct host OS drivers. Basically, if it works locally, and you can bring it into the guest, you can export it. V) Why are there two images? The Debian image has a work around to allow optical devices to work properly. Other than this difference, the two images should function as identical for other devices, host OS storage driver requirements not withstanding. See VI) for more information. --=-8hnWZBlOBQ9Pwg5977DM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Grettings all,

It is my great honor to announce that the LIO-VM Target images are now online and available for download:

http://linux-iscsi.org/builds/LIO-VM/vmware/

and the wiki entry (which is basically the README now) is also online:

http://linux-iscsi.org/index.php/LIO-VM

Please check the wiki for the complete release information.  Here are the bullets from the README.

Have Fun!!! :-)

--nab

----------------------------------------------------------------------------------------------------------------------------------

Introduction:

The LIO-VM Storage Engine demo is a set of  VMware compatible virtual machine images that contains
a self-configuring iSCSI storage engine that runs on with a very large and diverse amount of PC storage
software and hardware.  When the LIO-VM image boots, the host local storage hardware that is made
available to the guest is exported as iSCSI target ports, and made available to both local and remote
iSCSI Initiator clients.

Note that the iSCSI target is configured to allow _ALL_ iSCSI Initiators to access _ALL_ iSCSI Target Ports
across all available iSCSI Network Portals.  By default, the storage devices with filesystems will be exported
as READ-ONLY to prevent multiple accesses by non-cluster filesystems.  Support for production R/W
configurations of this demo are in the works, please stay tuned to the site and lists for more information
as this unfolds.  Also, if you really know what you are doing when it comes to non cluster filesystem + RW
access, please see section IX) below.

I) The .vmx LIO-VM images:

        There are two VMware Workstation 6.x/Fusion compatible image available:

        Debian Etch 4 i386: (2.6.18-5-686)
        JeOS / Ubuntu 7.10 i386: (2.6.22-14-virtual)

II) What are the host OS requirements to run the LIO-VM Demo?

        Any i386 or x86_64 Linux v2.6 host that can run VMware Workstation 6.
        Any Apple Mac-tel hardware that can run VMware Fusion.
        Any XP or NT compatible host that can run VMware Workstation 6.

III) What has been tested?

        The LIO-VM has been successfully run on Linux v2.6, MacOSX Leopard, and WinXP/NT.

        USB connected flash and SATA/PATA devices.
        Internal SATA DVD and External SATA HD drives
        External USB DVD/HD devices are also supported.

IV) What should work?

        All USB Direct-Access (flash, USB external PATA/SATA disk drives)
        All USB optical drives (CD, DVD, HD/DVD and BD)
        All PATA/SATA disk drives
        All PATA/SATA optical drives (CD, DVD, HD/DVD and BD)
        All PSCSI / FC / SAS hardware with correct host OS drivers.

        Basically, if it works locally, and you can bring it into the guest,
        you can export it.

V) Why are there two images?

        The Debian image has a work around to allow optical devices to work properly.
        Other than this difference, the two images should function as identical for other
        devices, host OS storage driver requirements not withstanding.  See VI) for
        more information.

--=-8hnWZBlOBQ9Pwg5977DM-- --===============0742105643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0742105643==--