On Monday 27 February 2006 22:03, Ian Levesque wrote: > Hi Kern, et al, > > >>>>> I've noticed a pattern in my backups when two jobs are > >>>>> simultaneously > >>>>> writing to the same tape. When the tape ends, Bacula doesn't > >>>>> respond > >>>>> gracefully. This is only a problem when two jobs are running on > >>>>> the > >>>>> tape, not when a single job is running. > >>>> > >>>> Are you spooling to disk or writing directly to tape? > >>> > >>> I'm writing directly to tape. Do you suppose that this may be > >>> remedied by > >>> spooling? My initial tests with spooling showed a performance hit > >> > >> It's clear you've tickled a bug and I hope you've filed it on > >> bugs.bacula.org. > > > > I think it is more likely that the user did not properly test with > > btape test. > > Yeah, it might appear that way :) > But I did perform the btape tests, and everything checked out OK. > > > I cannot completely exclude a bug, but I find it unlikely. I'd like > > clear > > evidence of a bug, which I don't have, before spending any time on the > > problem. > > Maybe it's not a bug in bacula. This is why I haven't filed one yet. > Perhaps it's a problem with my setup. I'm just looking for ideas, and > I find it curious that one-at-a-time jobs work as expected, while > simultaneous jobs will produce these errors more often than not.
I think the single/multiple job problem is just a coincidence. In fact, the output that I saw seemed to me to be non-fatal. That is, unless disabled via the conf Bacula tries to backup and re-read the last block successfully written. Many tape drives do not support backing up and re-reading, though most modern drives do. In your case, it appears that there is no logical end of tape marker on the tape (a tape defect or a drive LEOF detection defect) and so Bacula wrote to the end of the tape. This is not a very good thing, but not necessarily fatal. With most OS drivers, if you write to the very end of the tape, it is likely that the driver will get a bit confused about positioning, or will simply refuse to let you reposition the tape until you rewind or close the drive (rather logical). This is what I suspect happened to you. My best guess is a tape defect. If it happens with more than one tape, either you have a bad batch of tapes, or you have a defective drive or the logical end of tape reader head is dirty. On the other hand, I cannot 100% exclude the possibility that some lower level Bacula subroutine releases the device lock thus allowing some race condition with other threads (jobs). I'll take a look at the code with that in mind in the near future -- this week I'm tied up with family visitors so don't have much time. Unfortunately, testing such a problem is not easy as it takes a long time to write most tapes (especially LTOs). ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
