[Veritas-bu] Does SSO Use SCSI Reserve/Release?

On Thu, May 31, 2001 at 09:55:36AM -0700, W. Curtis Preston wrote:


I think it should #2. 
1) Some Unix flavors doesn't support reserve/release 
feature for example SGI. Not sure about NT/2000 
2) Solaris supports this feature.
But.... The "right" description for DLT tape drives we received from 
Veritas:

Q-DLT7000 = 1,0x38,0,0x3D639,4,0x82,0x83,0x84,0x85,2; 

# man st 
NAME
     st - driver for SCSI tape devices

..............skiped...
<options> is a bit  pattern  representing  the  devices,  as
     defined   in   /usr/include/sys/scsi/targets/stdef.h.  Valid
     flags for tape configuration are:
     ST_VARIABLE                            0x0001
     ST_QIC                                 0x0002
     ST_REEL                                0x0004
     ST_BSF                                 0x0008
     ST_BSR                                 0x0010
     ST_LONG_ERASE                          0x0020
     ST_AUTODEN_OVERRIDE                    0x0040
     ST_NOBUF                               0x0080
     ST_KNOWS_EOD                           0x0200
     ST_UNLOADABLE                          0x0400
     ST_SOFT_ERROR_REPORTING                0x0800
     ST_LONG_TIMEOUTS                       0x1000
     ST_BUFFERED_WRITES                     0x4000
     ST_NO_RECSIZE_LIMIT                    0x8000
     ST_MODE_SEL_COMP                       0x10000
     ST_NO_RESERVE_RELEASE                  0x20000
     ST_READ_IGNORE_ILI                     0x40000
     ST_READ_IGNORE_EOFS                    0x80000
     ST_SHORT_FILEMARKS                     0x100000
     ST_EJECT_TAPE_ON_CHANGER_FAILURE       0x200000
     ST_RETRY_ON_RECOVERED_DEFERRED_ERROR   0x400000

So, 0x3D639 has ST_NO_RESERVE_RELEASE bit set to 1

    ST_NO_RESERVE_RELEASE
               The ST_NO_RESERVE_RELEASE flag disables the use of
               reserve  on  open  and  release  on  close.  If an
               attempt to use a ioctl of MTRESERVE  or  MTRELEASE
               on  a  drive with this flag set, it will return an
               error of ENOTTY (inappropriate ioctl for device).





> I'm getting conflicting information from a couple of different sources, and 
> I KNOW that someone out there knows the real answer.
> 
> How does SSO (for NetBackup & BE if possible) managed contention for the 
> robot? It would seem that this could be done in one of two ways:
> 
> 1. It uses the SCSI Reserve command when it starts to use the arm.
>     If no other host is using it, the command will work, and it will proceed.
>     If another host is using it, the command will fail, and it will have to 
> be retried.
> 
> 2. It doesn't need to use the SCSI Reserve command, because it is accepting 
> all the requests.
>     Requests for the robot are "queued," and each host needing the robot is 
> told to wait it's turn.
>     SCSI Reserve is not needed, because the software will insure that only 
> one robotic command is issued at a time.
> 
> 3. Same as #2, except it also uses SCSI Reserve.  It doesn't NEED to, but 
> it does anyway.
>     Why?  I don't know. ;)
> 
> It would SEEM that #2 would be preferable.
> 
> 
> 
> ---
> W. Curtis Preston
> Principal Consultant for Storage Designs, your storage experts
> Webmaster: http://www.backupcentral.com Phone: 760 631 7991
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

-- 
----
Andrew Shinkarev
Network Systems Specialist
Abbott Laboratories
(847) 9387559
shinkara AT pprd.abbott DOT com