Running without reserve/release means any machine can start talking to the
tape device. Nothing stops node A from sending a 'mt -f /dev/rmt/0
rewoffl'
while node B is running a backup. The entire purpose of reserve/release is
to prevent such mishaps.

If a cluster node crashes and another node takes over, it will be the
responsibility of that node to reset all peripherals it now controls to a
known state. If the tape drive is reserved by the crashed node, the
surviving node can send a SCSI reset to lift the reserve condition.

Of course, message code 0x0c (Bus Device Reset) from any other
initiator can release this reservation, good point, thank you Rob.

In a shared storage environment this may be unwanted behaviour, in that
case
a node can use persistent reservation to keep a device tied to a certain
node, regardless if it's up or crashed.

You're right, persistent reservation is the solution. I've just checked my
T10
specifications for that particular command. The interesting thing is that
I've
never recognized that command during scsi or fc/fcp analysis - well, in fact
I did such kind of deep protocol digging very seldom, approx. 2 per year
during
the last 2-3 years.

Anyway, my question now is if current device drivers (for tape drives) or
applications (Legatos DDS or Veritas' Master/Media Server) are familiar with
the usage of that command. Or in other words, this persistent reservation
feature seems to be a very useful command for safety reasons, that should be
in use in any tape sharing environment.

Rene