What are SCSI Persistent Reservations?

Do NetApp storage systems support SCSI reservations?

Resolving SCSI reservation conflicts from the Host.
SnapDrive errors related to SCSI reservation conflicts.
Resolving SCSI reservation conflicts from the NetApp storage system.
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 Logical Unit Number (LUN) in order 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:

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 reserverequest is sent to the target using the APTPL
flag.
SCSI reservations are used by NetApp storage systems for several reasons:
1. 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.
2. 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. For more information on using this
setting, see the Data ONTAP 7.0 Data Protection Tape Backup and Recovery Guide.

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. For more information on using this
setting, see The Data ONTAP 8.0.1 Data Protection Tape Backup and Recovery Guide.
3. 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:

Will
Yes

a SCSI taarget

Will
No

the lun

reset

reset or target

or

lun

reset command

reset commands

affect

clear

SCSI-3

SCSI-2

reservation?

Persistent

Reservations?

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
Yes. All initiators mapped to a specific LUN will receive a LUN RESET notification.

specific

LUN?

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
Related Links:

SCSI-3 Protocol Reservations

BUG 158042: SCSI Reserve and Release needed for fiber-channel-attached tape drives and libraries

Disclaimer
NetApp provides no representations or warranties regarding the accuracy, 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 customers responsibility and depends on the customers ability to
evaluate and integrate them into the customers operational environment. This document and the information
contained herein may be used solely in connection with the NetApp products discussed in this document.