Understanding Linux SCSI Reservations (sg_persist and mpathpersist)

Updated: 28 September 2026 · Applies to: sg3_utils 1.46 to 1.48 and device-mapper-multipath on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13

When several servers are connected to the same shared disk (a SAN LUN), they must not write to it at the same time unless the file system is built for that. SCSI reservations are the disk's own locking mechanism: a server registers a key with the disk and can then reserve it, so that other servers are refused. High-availability clusters use this for fencing, to stop a failed node from damaging shared data. You normally see reservations when a cluster sets them, or when a disk refuses access because another node still holds one.

Two kinds of reservation

• SCSI-2 reservations (RESERVE and RELEASE): the older form. One initiator holds the disk; a bus reset clears it. It does not work well with multipath and is rarely used today.
• SCSI-3 persistent reservations: each server (initiator) registers a key, one holds the reservation, and the state survives resets and path failures. Pacemaker's fence_scsi agent and most current storage use these.

Inspect persistent reservations

Install sg3_utils (dnf install sg3_utils or apt install sg3-utils), then:

sg_persist --in --read-keys /dev/sdc          # registered keys
sg_persist --in --read-reservation /dev/sdc   # who holds the reservation, and its type
sg_persist --in --report-capabilities /dev/sdc

With multipath, query the multipath device instead of a single path, using mpathpersist from the device-mapper-multipath package:

mpathpersist --in --read-keys /dev/mapper/mpathc
mpathpersist --in --read-reservation /dev/mapper/mpathc

Register, reserve and release (for testing or recovery)

sg_persist --out --register --param-sark=0x1a2b /dev/sdc
sg_persist --out --reserve --param-rk=0x1a2b --prout-type=5 /dev/sdc
sg_persist --out --release --param-rk=0x1a2b --prout-type=5 /dev/sdc

Type 5 is "write exclusive, registrants only": every registered server may write, others may only read. Clusters choose the type themselves.

Clearing a stale reservation

If a disk stays locked after a node was removed, and you are sure no cluster node is using it, a registered initiator can clear all keys and the reservation:

sg_persist --out --clear --param-rk=0x1a2b /dev/sdc

Do this only with the cluster stopped or with the storage team's agreement: clearing reservations in a running cluster removes its protection against data corruption.

Symptoms of a reservation conflict

• Kernel messages with "reservation conflict" in journalctl -k.
• I/O errors on one server while another works normally with the same LUN.

Official documentation: sg3_utils (includes sg_persist) and Configuring device mapper multipath (Red Hat).