Skip to main content
NetApp Knowledge Base

What are SCSI Reservations and SCSI Persistent Reservations?

  1. Last updated
  2. Save as PDF
Views:
28,775
Visibility:
Public
Votes:
70
Category:
clustered-data-ontap-8
Specialty:
SAN
Last Updated:

Applies to

  • ONTAP 9
  • Clustered Data ONTAP 8 
  • Data ONTAP 7 and earlier 
  • Flexpod

Question(s) and Answer(s)

What are SCSI reservations and SCSI-3 Persistent Reservations?

  • SCSI reservations are used to control access to a shared SCSI device such as a disk or tape drive.
  • An initiator sets a reservation on a LUN to prevent another initiator from making changes to the LUN. This is similar to the file-locking concept. SCSI reservations are always set by a host initiator. Ideally, the same initiator would perform a SCSI release on the affected LUN. 
  • The mechanics of SCSI reservations are specified in the SCSI protocols. As specified in these protocols, reservations are used to control access to a device.
  • The original SCSI reservation mechanism was called SCSI Reserve and Release, also known as SCSI-2 Reservations. Under this mechanism, an initiator would set a reservation using the SCSI Reserve command. This reservation could be released by the owning host issuing a SCSI Release command or by a SCSI bus reset. Thus, a SCSI bus reset performed due to an error recovery would cause the reservation to be released.
  • The SCSI-3 Primary Commands specification provides for a modern approach to reservations known as Persistent Reservations. Persistent Reservations add the ability for the reservation to persist even if the bus is reset for error recovery. These are set using the SCSI Persistent Reserve Out and Persistent Reserver IN commands. Although SPC-2 supports both Reserve and Release and Persistent Reservations, the two mechanisms are mutually exclusive.
  • If a classic reservation is placed on a device, all subsequent Persistent Reservation requests will fail until a classic Release is performed. The newer SPC-3 specification deprecates classic Reserve and Release mechanisms in favor of Persistent Reservations.
  • The SCSI protocol specification provides more details on reservations.

How do SCSI-3 Persistent Reservations Work?

  • SCSI-3 Persistent Reservations supports multiple nodes accessing a device while at the same time blocking access to other nodes. SCSI-3 Persistent Reservations also support multiple paths from host to disk whereas SCSI-2 reservations do not and could only work with a single path to the LUN.
  • SCSI-3 Persistent Reservations uses a concept of registration and reservation. Systems that participate, register a key with the LUN. Each system registers its own key. After this, registered systems can establish a reservation. With this method, blocking write access is as simple as removing registration from a device. A system wishing to eject another system may register, clear or preempt the other registered initiators. This method effectively avoids the split-brain condition.
  • Persistent reservations allow multiple clients (initiators) to communicate with a target by tracking multiple initiator-to-target relationships called I_T nexuses. An I_T nexus is a relationship between a specific SCSI initiator port and SCSI target port for a given LUN within the SCSI target. 
  • The first step in setting up a Persistent Reservation is the registration of a Reservation Key. A Reservation Key is specific to each I_T nexus and includes the necessary information to allow the authentication of the I_T nexus devices in order to control the reservations.

Persistent reservations have two commands:

  • persistent reserve in: Used by the initiator to read information on the target about existing reservations and registrations.
  • persistent reserve out: Used by the initiator to register, set and alter its reservations, and break reservations for error recovery.

The SCSI Persistent Reservation commands also use subcommands called Service Actions to perform specific functions such as reserving and releasing reservations. The following is an example of how a Persistent Reservation is set using the persistent reserve out Service Actions:

 

SCSI Reservations and SCSI Persistent Reservations

 

When a reservation conflict response is sent from the target to an initiator, the conflicting initiator will need to retry the reserve request. The host initiator's OS will control at what interval the reserve request is retried. The conflicting host will continue to get a reservation conflict status from the target, until one of the following events occurs:

  • The controlling host sends a release command.
  • A SCSI bus device reset is issued from any initiator.

Note: SCSI-3 Persistent Reservation might be retained across power cycles of the target device. This behavior is determined by the initiator at the time the reservation reserve request is sent to the target using the APTPL flag.

 

SCSI reservations are used by NetApp storage systems for several reasons:
  • In a SAN environment, the NetApp fabric-attached storage system will set and honor classic release/reserve and persistent reservations for LUNs requested by initiators.
  • In a tape backup environment, the storage system can be configured to use SCSI reservations to reserve tape drives in a Dynamic Drive Sharing environment. 
    • In Data ONTAP releases prior to 7.1.1, SCSI reserve/release reservations were controlled by the options tape.persistent_reservations [on | off] command. 
    • Data ONTAP 7.1.1 and later added the ability to set either SCSI reserve/release or SCSI Persistent Reservations. The options tape.persistent_reservations command was deprecated and replaced with the options tape.reservations [scsi | persistent] command. 
  • NetApp High Availability (HA) storage controllers use SCSI reservations to control disk access.
    • For HA pairs using hardware disk ownership, SCSI reservations are only used during cf takeover.  
    • For HA pairs using software disk ownership, SCSI reservations are used regardless of whether the system is in cf takeover.
  • They are not persistent across power cycles of the disk shelves. Because of this, the node that has taken over will reassert the reservation at regular intervals in case the disk shelves lose power or a drive is reset.
  • While it is possible to see that a reservation exists, it is not possible to determine which node set the reservation.
  • Active-active cluster partners using SANOWN (Software Disk Ownership) use SCSI-3 Persistent Reservations to control disk ownership.
  • The reservations are used regardless of whether the HA pair is in cf takeover. These reservations are persistent across reboots.
  • The node owning the reservation has complete control over the disk, including read and write capabilities.
  • The SCSI-3 Persistent Reservations are reasserted every 30 seconds. 

 

Resolving SCSI-2 reservation conflicts from a Host

How do lun reset and target reset commands affect SCSI-2 Reservations?

  • Using host based software is the best way to clear SCSI reservations. Typically, LUNs are mapped to a single host. However, in the case of a host cluster, the same LUNs are usually mapped to all cluster nodes.
  • In some cases, it might be necessary for a host to clear a reservation that it did not initiate.  This is done through the use of the lun reset and target reset SCSI commands.


How does the storage system respond when it receives the lun reset or target reset command?

  • The following messages will be logged when a reset is received:
  • Mon Jan 5 18:19:40 CST [storage1: scsitarget.ispfct.lunReset:notice]: FCP Target 5a: LUN 0 was Reset by the Initiator at Port Id: 0x74001f (WWPN 5001438002210a3e)
  • Mon Jan  5 18:18:01 CST [storage1: scsitarget.ispfct.targetReset:notice]: FCP Target 6a: Target was Reset by the Initiator at Port Id: 0x1d3600 (WWPN 500508b200b65d52)


Do you have to use a specific LUN when issuing the target reset command?  

  • The target reset command can be sent by an initiator without addressing a specific LUN, but a lun reset needs to be addressed to a specific LUN.

 

Warning: A target reset will abort all commands on all LUNs mapped to the initiator that issued this command.  It will also abort commands from other initiators to the LUNs that are accessed by the initiator from which the abort was initiated.

 

Example:

Resolving SCSI-2 reservation conflicts from a Host

 

Will a SCSI target reset or lun reset command clear a SCSI-2 reservation? 
    Yes

Will the lun reset or target reset commands affect SCSI-3 Persistent Reservations? 
    No

Can the SCSI lun reset command be issued from any initiator on any host that has visibility to this LUN?
    Yes. However, the lun reset command needs to be addressed to a specific LUN.

Will a SCSI lun reset affect any other initiators that are logged into a specific LUN? 
    Yes. All initiators mapped to a specific LUN will receive a LUN RESET notification. 

Will the SCSI target reset command affect all LUNs from all initiators that are logged into a target LUN? 
    A target reset on a NetApp SCSI target resets only those LUNs that are mapped to the initiator that is sending the target reset command.

SnapDrive errors related to SCSI reservation conflicts
  • When attempting to connect to a LUN using SnapDrive, these errors can appear:
  • Unable to locate a LUN to perform requested operation.
  • The LUN has SCSI reservation but has not been mapped.
  • On the windows host, in Computer Management > Disk Management, the disks can also show as Unknown/Unreadable.
  • This can be resolved by clearing the SCSI reservations.

 

 

It is recommended to use host based software to clear these reservations.

If this is not working, it can be done by an Escalation Engineer from NetApp Global Support - from the storage system if necessary.

Resolving conflicts of SCSI-3 Persistent Reservations from a NetApp Storage system - Contact NetApp Support before attempting to clear any reservations from the NetApp storage system.

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.