On Thursday 22 June 2006 17:49, Martin Simmons wrote:
> >>>>> On Thu, 22 Jun 2006 11:21:41 -0400, Dan Langille said:
> >
> > Priority: normal
> > Content-description: Mail message body
> >
> > 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.
> >
> > If you have "Fast Forward Space File = no", this process can take a
> > very very long time.
>
> True, but does it take a long time asynchronously in the tape drive or
> synchronously in the code that loops doing MTFSF? If the latter, then it
> can't be writing at the same time.
Bacula is single threaded for tape operations, so two separate operations on
the tape drive at the same time are not possible.
>
> Maybe the correct response to EBUSY it to wait and try again?
That is true. But Bacula uses blocking mode, and the drive should never
return EBUSY -- I have never seen it in 6 years of working with Bacula.
> But would that happen during a call to write()?
It could if it were non-blocking and the OS buffers are full for some reason
(perhaps a recoverable error on the drive that takes a bit of time to work
out).
Is this problem happening only on FreeBSD systems? If so, what version?
--
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
