Hi,
12.05.2008 06:42, Maria McKinley wrote:
> Hey all,
>
> I have a tape changer, and backup took more than the normal amount of
> tapes this time. It was requesting a tape that wasn't in the changer,
> but there was a Scratch pool tape in the changer. I guess I should have
> a longer retention time, so that it thinks there aren't any available
> from the usual pool, and takes the Scratch tape automatically. So, I
> thought I would just change the scratch pool tape into the weekly pool,
> and then it would use that instead of the other tape it wanted. That is
> what I did:
>
> Current Pool is: Scratch
> Enter new Pool name: Weekly
> New Pool is: Weekly
A 'mount' at this time should have been sufficient.
> *update slots
Though the 'update slots' shouldn't do any harm.
> Automatically selected Storage: Exabyte
> Connecting to Storage daemon Exabyte at billie:9103 ...
> 3306 Issuing autochanger "slots" command.
> Device "Exabyte" has 10 slots.
> Connecting to Storage daemon Exabyte at billie:9103 ...
> 3306 Issuing autochanger "list" command.
> Catalog record for Volume "G0000003" updated to reference slot 1.
> Catalog record for Volume "G0000002" updated to reference slot 2.
> Catalog record for Volume "G0000004" updated to reference slot 3.
> Catalog record for Volume "G0000005" updated to reference slot 4.
> Catalog record for Volume "G0000006" updated to reference slot 5.
> Catalog record for Volume "G0000007" updated to reference slot 6.
> Catalog record for Volume "G0000001" updated to reference slot 7.
> Catalog record for Volume "G0000008" updated to reference slot 9.
> Catalog record for Volume "CLNA0001" updated to reference slot 10.
> Catalog record for Volume "F0000009" updated to reference slot 8.
> *
> *mount
> Automatically selected Storage: Exabyte
> 3001 OK mount. Device="Drive-1" (/dev/st0)
> *
>
> And, it seemed maybe it had worked:
>
> *
> 11-May 20:48 billie-sd JobId 546: 3307 Issuing autochanger "unload slot
> 8, drive 0" command.
> *
> but then:
> You have messages.
> *messages
> 11-May 20:49 billie-fd JobId 546: Fatal error: backup.c:892 Network send
> error to SD. ERR=Broken pipe
> 11-May 20:49 billie-fd JobId 546: Error: bsock.c:306 Write error sending
> 65536 bytes to Storage daemon:billie:9103: ERR=Broken pipe
> 11-May 20:49 billie-dir JobId 0: Warning: bsock.c:123 Could not connect
> to Storage daemon on billie:9103. ERR=Connection refused
> Retrying ...
>
> it did this a few times, and then:
> 11-May 20:49 billie-fd JobId 546: Fatal error: backup.c:892 Network send
> error to SD. ERR=Broken pipe
> 11-May 20:49 billie-fd JobId 546: Error: bsock.c:306 Write error sending
> 65536 bytes to Storage daemon:billie:9103: ERR=Broken pipe
>
> At this point, the storage daemon was no longer working.
>
> So, should I have not used the mount command?
The mount command should have been ok.
> Would it have sorted
> things out, if I had just left it alone after moving the tape to the
> Weekly pool, or can I just not move tapes like this?
It would have sorted things out automatically at the next retry to
access a useable tape, too.
This looks similar to something reported recently, and something I saw
at a customer - the SD simply died without any message.
I could not reproduce this issue, by the way.
If you can reproduce it, capture the debug log from the SD and report
it as a bug. I don't think you did anything wrong, and even if you
did, user errors must not lead to a SD crashing...
Arno
> thanks for any help,
> maria
--
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
