Hello,

I might well have added some additional insanity checks to guard against bad 
tapes or bad tape drives, and this could be interacting with the poll 
feature.  

Why don't you up your poll interval to 5 minutes and see if that increases the 
time Bacula waits before giving up.  If it does, then at least you have a 
work around -- increase the poll interval to be sufficiently long that it 
will not fail, or disable the polling and simply "mount" the drive.

In the mean time, I'll take a look at the various insanity checks that I have 
(particularly any that I added) ...

On Sunday 13 November 2005 19:42, Steve Ellis wrote:
> I'd been eagerly awaiting 1.38, as well as eagerly awaiting a much better
> tape drive, now I have both, which made me very excited (both the new
> features in 1.38 and the LTO2 drive that is replacing my DDS4 are
> _extremely_ cool), but see a different and undesirable behavior with 1.38
> (even on my old tape drive).
>
> A little background:
>
> My server runs headless downstairs in the garage, I usually get to the
> bacula console from my desktop machine upstairs, and I don't have an
> autoloader.  Consequently, it is much more convenient if bacula spits out
> the tape that it doesn't want (if it is full, or I forgot to change it),
> and waits for me to insert the correct tape.  Previously, in 1.36.?, with
> my config (below), bacula would patiently wait a long, long time for me to
> get around to giving it the tape it wanted.  When I gave it the tape it
> wanted, it would automatically mount and start using it.  Now, it looks
> like it is only willing to wait about 25 minutes before giving up, and if
> the drive is unloaded, all subsequent jobs (requiring the same device)
> fail 20 or so minutes after they start too.
>
>
> My guess is that there is now a limit on the number of times bacula will
> poll the device waiting for the new tape, and since I've set a pretty
> short poll interval (1 minute), it gives up too easily.
>
> Actually, I believe this was a problem in an earlier release, which Kern
> fixed when I saw it, but it was fixed in the 1.36 build I was using (which
> I hope wasn't my own local customization).
>
> At any rate, anyone who wants to operate their drive in the way I do will
> hit this problem if they are not quick in putting in the correct tape,
> unless there is a config file option to control the number of polls of
> which I am not aware (I did look in the manual section for the device
> configuration and didn't see anything).  If there is another way to
> accomplish what I want, or even something close to what I want, I'd like
> to hear about it.
>
>
> -se
>
> Here's the relevant clip from my bacula-sd.conf:
>
> Device {
>   Name = DDS4
>   Media Type = DDS-4
>   Archive Device = /dev/nst1
>   Automatic Mount = Yes               # when device opened, read it
>   Always Open = Yes
>   Volume Poll Interval = 1 min
>   Close On Poll = Yes
>   Offline On Unmount = Yes
>   Removable Media = Yes
>   Random Access = No
>   Maximum Spool Size = 10737418240
>   Spool Directory = /backup/bacula/spool
>   Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
>   Maximum Network Buffer Size = 262144
> }

-- 
Best regards,

Kern

  (">
  /\
  V_V


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to