(I suspect that this should be setup in the FAQ somewhere)


Now that I've got a better understanding of the problem, I see two 
options for fabric connected tape drives (usually inside a library)

1: Send unlock commands to all instances of the tape drive - this 
requires that all instances are known to bacula or the scripts it calls.

This can be hacked up fairly quickly and I may be able to create some 
udev rules to reduce the necessity to scan for tapedrive WWIDs at each 
mtx-changer call.

OR

2: Have an option not to lock the drive in the first place (bacula-sd)


Here's a better explanation of the problem as reported on HP's forums.

=====

https://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1466961

"...prevent/allow settings are per initiator/target connection so a 
single host can have multiple connections and send a prevent over one 
then for some reason switch to a different port - the allow has to come 
from the same port as the prevent"

"The SCSI standards require that the drive logically OR all of the PAMR 
settings for the different initiators and if any of them are set to 1 
then media removal is prevented and in this case media removal is 
prevented by the host with the WWN shown above."

====



------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users