Arno, On Sunday 09 September 2007 08:07:42 pm Arno Lehmann wrote: > Hi, > > 10.09.2007 00:51,, Ivan Adzhubey wrote:: > ... > > > On a related issue: I have asked this question before but never get any > > answer. > > > > Documentation states (from Data Spooling article): > > > > "While the spooled data is being written to the tape, the despooling > > process has exclusive use of the tape. This means that you can spool > > multiple simultaneous jobs to disk, then have them very efficiently > > despooled one at a time without having the data blocks from several jobs > > intermingled, thus substantially improving the time needed to restore > > files. While despooling, all jobs spooling continue running." > > > > I have always had spooling enabled and the behaviour I observed through > > several versions of Bacula (from 1.36.2 to 2.2.1) was never anything like > > the described above. In reality, with simultaneous jobs enabled, several > > jobs were happily despooling to the same tape drive simultaneously (until > > I take countermeasures in the configuration to prevent this) wrecking > > havoc on my tapes. I think the documented behaviour would make much sense > > and would have prevented the MediaId bug from stricking. If only it would > > be actually implemented... > > My experience is quite different and fits the manual: While one job is > despooling, all other jobs using the same tape drive are either > spooling (no problem) or waiting for despooling. This is the case on > Bacula versions from 1.38.something to 2.0.3 at least.
I am pretty sure I've witnessed this wrong behavior with my own eyes last time with version 2.2.0 but I might as well be misinterpreting what was going on. But if you are right and simultaneous tape writes from different jobs should never happen with spooling enabled, does this mean that this dreaded MediaId bug should not occure with this configuration too? Sorry, this is a question for Kern I guess. > I would suggest to turn on debug logging before the jobs start and > trace what the SD does, until more than one job actually writes to > tape. At a debug level that reports the device reservation process and > actual block writes to tape, the resulting trace will might get really > huge, though... > > Anyway, perhaps you can identify where the SD allows multiple jobs > write access to the storage device - I found that I could understand > the trace file quite easily. Debugging on a production system is not what I am after frankly. We've already lost 2 months of backups due to problems with hardware and software upgrades on the server and right now I just can't stretch my luck any more. I may give it another shot later after I've run through at least one straight backup cycle though. At the moment, I would stick with the confuration workarounds I have in place already. I've learned them hard way ;). --Ivan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
