FW: Preempting all target ports

Mon Dec 1 09:18:03 PST 2003

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ulrich, David" <dulrich at lsil.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3B82F.0DED2588
Content-Type: text/plain;
	charset="iso-8859-1"

-----Original Message----- 
From: Ulrich, David 
Sent: Monday, December 01, 2003 8:11 AM 
To: 'Ralph Weber' 
Subject: RE: Preempting all target ports 

In regard to the case of a preempt with no reservation in place, I
haven't been able to find any explicit statements to indicate that the
I_T nexus that the command was issued on is exempt from the removal of
the reservation key.  Is there something specific that conclusion "a"
below is based on?

Best Regards, 

David Ulrich 
Staff Software Engineer 
LSI Logic Storage Systems 
3718 N. Rock Road 
(316) 636-8871 
david.ulrich at lsil.com 
www.lsilogicstorage.com 

> LSI Logic Storage Systems 
> AT THE HEART OF INFORMATION 
> 

-----Original Message----- 
From: Ralph Weber [ mailto:roweber at IEEE.org  ] 
Sent: Sunday, November 30, 2003 10:36 AM 
To: T10 Reflector 
Subject: Preempting all target ports 

* From the T10 Reflector (t10 at t10.org), posted by: 
* Ralph Weber <roweber at ieee.org> 
* 
Suppose that an initiator registers using the ALL_TG_PT option. 

Sometime later for whatever reason, the initiator decides to 
preempt its own reservation key. 

Would you expect that: 

  a) the registration is preempted on all target ports except 
     the target port through which the preempt was delivered, or 
  b) the registration is not preempted on any of the target 
     ports associated with the preempting initiator? 

I believe that SPC-3 says a). Furthermore, the a) interpretation 
is being solidified by seemingly editorial requests to change 
'initiator port' to 'I_T nexus' throughout the Persistent 
Reservations model. 

FYI 

.Ralph 

* 
* For T10 Reflector information, send a message with 
* 'info t10' (no quotes) in the message body to majordomo at t10.org 

------_=_NextPart_001_01C3B82F.0DED2588
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 FW: Preempting all target ports 

-----Original Message----- 
From: Ulrich, David 
Sent: Monday, December 01, 2003 8:11 AM 
To: 'Ralph Weber' 
Subject: RE: Preempting all target ports 
In regard to the case of a preempt with no = reservation in place, I haven't been able to find any explicit = statements to indicate that the I_T nexus that the command was issued = on is exempt from the removal of the reservation key.  Is there = something specific that conclusion ;a; below is based = on? Best Regards, David Ulrich 
Staff Software Engineer 
LSI Logic Storage Systems 
3718 N. Rock Road 
(316) 636-8871 
david.ulrich at lsil.com 
www.lsilogicstorage.com > LSI Logic Storage Systems 
> AT THE HEART OF INFORMATION 
> 
-----Original Message----- 
From: Ralph Weber [mailto:roweber at IEEE.org] 
Sent: Sunday, November 30, 2003 10:36 AM 
To: T10 Reflector 
Subject: Preempting all target ports 
* From the T10 Reflector (t10 at t10.org), posted = by: 
* Ralph Weber <roweber at ieee.org> 
* 
Suppose that an initiator registers using the = ALL_TG_PT option. Sometime later for whatever reason, the initiator = decides to 
preempt its own reservation key. Would you expect that:   a) the registration is preempted on all target = ports except 
     the target port through = which the preempt was delivered, or 
  b) the registration is not preempted on any = of the target 
     ports associated with the = preempting initiator? I believe that SPC-3 says a). Furthermore, the a) = interpretation 
is being solidified by seemingly editorial requests = to change 
'initiator port' to 'I_T nexus' throughout the = Persistent 
Reservations model. FYI .Ralph 
* 
* For T10 Reflector information, send a message = with 
* 'info t10' (no quotes) in the message body to = majordomo at t10.org 
------_=_NextPart_001_01C3B82F.0DED2588--