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. 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. -- Dan Langille : Software Developer looking for work my resume: http://www.freebsddiary.org/dan_langille.php 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
