(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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
