FCP-2 Table 4 Clearing Effects

Robert Snively rsnively at Brocade.COM
Fri Aug 11 15:09:49 PDT 2000

* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at Brocade.COM>

A LIP(F7) does not cause device reservations or any task to be cleared
unless the subsequent authentication protocol (FAN or ADISC/PDISC)
fails.  At that time, the reservation has no more meaning, since the
topology of the fabric or loop has changed in an unpredictable 
manner.  Various types of logouts are then expected and logins
and new registrations with name servers must be performed.  Only after
that recovery is completed would the topology again be known and
the devices again reservable and usable.

So the key is:

	Do not let a LIP(F7) create an authentication failure unless
	addresses and destination nodes have changed.

The secondary key is:

	Use persistent reservation, where the reservation can be
	corrected to reflect address changes if the WWN of a node and port
	is still consistent and known.

Then, you will only lose reservations when you really should lose them.

Note that PRLO or LOGO changes a SCSI device from an intelligent peripheral
to a block of aluminum that loses all SCSI state and cannot use
the FCP protocol (unless implicit logins are active).


>  -----Original Message-----
>  From: Lawrence Chen [mailto:Larry.Chen at ebay.sun.com]
>  Sent: Thursday, August 10, 2000 5:38 PM
>  To: t10 at t10.org
>  Subject: FCP-2 Table 4 Clearing Effects
>  Looking at FCP-2 Rev 04,
>  Table 4 - Clearing Effects of SCSI Initiator Actions
>  Can someone explain the rational for clearing Device Reservations for
>  For many pieces of FC hardware as of today, this means that Lip(F7)s
>  will cause Device Reservations to be cleared. I think this
>  behavior is too drastic in cluster configs; i.e.,  if one 
>  host is rebooting
>  then the other "alive" host's Device Reservation can get 
>  effected due to a
>  Lip(F7). Shouldn't the reboot be as transparent as possible 
>  to the "alive"
>  host ?? 
>  Lastly, I realize the Persistent Reservations do NOT behave this way
>  (but this won't help me here).
>  --
>  Larry Chen
>  Sun Microsystems, Inc.
>  Network Storage Division
>  Email: larry.chen at ebay.sun.com
>  Phone: (510) 574-9779  Fax: (510) 574-9822
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list