On Thursday 22 June 2006 19:15, Dan Langille wrote:
> On 22 Jun 2006 at 19:07, Kern Sibbald wrote:
> > On Thursday 22 June 2006 17:21, Dan Langille wrote:
> > > On 22 Jun 2006 at 17:09, Kern Sibbald wrote:
> > > > On Thursday 22 June 2006 14:17, James Cort wrote:
> > > > > A few weeks ago I posted to this list with a problem concerning my
> > > > > tapes encountering errors around the 100G mark which resulted in
> > > > > bacula ending them and moving onto another tape.
> > > > >
> > > > > As suggested, I swapped the SCSI card for an Adaptec unit, however
> > > > > the problem persists:
> > > > >
> > > > > 22-Jun 12:16 gemini-sd: Sending spooled attrs to the Director.
> > > > > Despooling 217,482,871 bytes ...
> > > > > 22-Jun 12:42 gemini-sd: Committing spooled data to Volume.
> > > > > Despooling 18,631,986,113 bytes ...
> > > > > 22-Jun 12:42 gemini-sd: cygnus_new.2006-06-22_08.58.01 Error:
> > > > > block.c:552 Write error at 104:2205 on device /dev/nst0. ERR=Device
> > > > > or resource busy.
> > > >
> > > > The problem is coming from the above. You will need to figure out
> > > > why the device is reporting that it is busy when Bacula attempts to
> > > > write to it. This error message should *never* happen. It is as if
> > > > your tape drive is in non-blocking mode, which should be impossible,
> > > > and what should happen is that the write() should simply block.
> > > >
> > > > My suggestion would be to upgrade to 1.38.10, which will be a bit of
> > > > work since it is a database update. At that point, at least I could
> > > > provide you with a patch that could attempt to recover from the
> > > > problem ...
> > > >
> > > > If you upgrade, please read the release notes carefully especially
> > > > those concerning 1.38.0 where most of the big upgrade problems were
> > > > identified.
> > >
> > > A similar issue was discussed on IRC recently. This situation *may*
> > > arise when the tape drive is busy finding the end of the volume.
> > > i.e. spacing forward.
> >
> > This is impossible unless your OS is broken. Bacula will never try to
> > write while it is spacing to the end of the volume.
>
> I have not read deeply into this thread so I suspect I have
> misunderstood the issue.
>
> > > If you have "Fast Forward Space File = no", this process can take a
> > > very very long time.
> >
> > True, but it could not be the source of the error here. When operating
> > on a tape, Bacula is single threaded.
> >
> > > If you do try changing that setting to yes, it is best practice to
> > > rerun the standard tape tests suggested in the Bacula documention.
> > > Indeed, after any such changes to your tape device configuration.
> >
> > I don't understand the above. It seems totally out of context. What is
> > "chaning that setting to yes" mean????
>
> If someone wants to change "Fast Forward Space File" from "no" to
> "yes", they should rerun the standard tests.
OK, I see what you mean. That is completely correct.
>
> It is all moot. I didn't realise this problem was occuring during
> writing. I saw the problem I described this morning. In this case,
> the SD was waiting a very long time when starting up a job.
I don't know if you have seen the bugs database yet, but there is one user who
claims that Bacula 1.38.10 crashes on FreeBSD 6.1.
--
Best regards,
Kern
(">
/\
V_V
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
