"How to verify that the disk is iscsi3 persistent compliant"

Latest response

"How to verify that the disk is iscsi3 persistent compliant"

Responses

Do you mean SCSI-3 persistent reservations? That is a SCSI feature that can be used with all SCSI-based disk interface technologies, including iSCSI.

The SCSI-3 persistent reservations features of a disk can be queried and tested with the sg_persist command, which is included in the sg3_utils RPM package.

You can attempt to read the persistent-reservations capabilities of a disk/LUN with the "sg_persist -d /dev/ -c" command.

If the disk/LUN won't support SCSI-3 persistent reservations, the commands will respond with a "command not supported" error message:

[root@localhost ~]# sg_persist -d /dev/sda -c
  ATA       VBOX HARDDISK     1.0 
  Peripheral device type: disk
PR in (Report capabilities): command not supported

If the disk/LUN claims to support SCSI-3 persistent reservations, you'll get a longer response:

# sg_persist -d /dev/sde -c
  IBM       2145              0000
  Peripheral device type: disk
Report capabilities response:
  Compatible Reservation Handling(CRH): 1
  Specify Initiator Ports Capable(SIP_C): 0
  All Target Ports Capable(ATP_C): 0
  Persist Through Power Loss Capable(PTPL_C): 1
  Type Mask Valid(TMV): 1
  Allow Commands: 0
  Persist Through Power Loss Active(PTPL_A): 0
    Support indicated in Type mask:
      Write Exclusive, all registrants: 1
      Exclusive Access, registrants only: 1
      Write Exclusive, registrants only: 1
      Exclusive Access: 1
      Write Exclusive: 1
      Exclusive Access, all registrants: 1

The above commands are sufficient to verify if the disk/LUN claims to support SCSI-3 persistent reservations or not.

If you actually need to verify that the reservations are implemented according to spec, you'll probably need to present the disk/LUN to at least two systems and then use the sg_persist command to set up all the various types of reservations one at a time from one system, and then try and access the disk/LUN from the other system, and verify that the reservations block either write access or all access to the disk/LUN from the system that is not currently holding the reservation.

Great piece of information, thank you!

Useful info. Thank you!