Hi, Bacula 7.0.2 on RHEL6 installed from the slaanesh EPEL repository. The autochanger is a Dell PV-124T with 8 slots and a single LTO-5 drive.
I'm wondering if anyone else has seen this behavior. I successfully ran a btape "test", including the autochanger tests. I can write and read tar files from tape. mtx-changer works as expected. Everything appears to be working except the verify stage of btape fill. btape fill writes to the first tape, switches to the second tape writes a few more blocks there and then switches back to the first tape for verifying. At that point it loads, then unloads, the tape. Here is the first iteration of the loop btape is stuck in. ----- 14:42:16 Done filling tapes at 0:1003. Now beginning re-read of first tape ... btape: btape.c:2481-0 Enter do_unfill 09-May 14:42 btape JobId 0: 3307 Issuing autochanger "unload slot 2, drive 0" command. 09-May 14:43 btape JobId 0: 3304 Issuing autochanger "load slot 1, drive 0" command. 09-May 14:44 btape JobId 0: 3305 Autochanger "load slot 1, drive 0", status is OK. 09-May 14:45 btape JobId 0: 3307 Issuing autochanger "unload slot 1, drive 0" command. 09-May 14:46 btape JobId 0: Warning: acquire.c:276 Read acquire: vol_mgr.c:382 Could not reserve volume "TestVolume1" for append, because it will be read. ----- So btape loads the correct tape, gets an OK status, then unloads the tape and warns that it couldn't be reserved for append because it will be read. Why is it trying to reserve for append? It should only be reading now if I understand things properly. I think this is probably a bug? After two tries I am prompted to mount TestVolume1 and press enter when ready. I manually loaded the tape from another terminal and after hitting enter in the original btape process, btape tries twice more and prompts me again. etc. I also checked the volume label in another terminal (with btape readlabel) and it *is* called TestVolume1. Any ideas? I'd like to see it pass this test but I am probably going to move soon to a real backup/restore and see if that succeeds. - Bill Hamblen ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users