Hi Arno, On Monday 10 September 2007 04:18:49 am Arno Lehmann wrote: > Hi, > > 10.09.2007 02:23,, Ivan Adzhubey wrote:: > > 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 think I have one plausible explanation of what might actually cause the behavior I observed. This is only a wild guess however so I would appreciate if someone from developers could take a look at the code and correct me if I am wrong. Specifically, what happens if the spooling space on disk gets filled (up to a limit specified in director config or just by filling up the whole disk partition) and there are multiple simultaneous jobs all in the process of spooling to this same disk? My initial understanding (supported by nothing but my imagination - there is nothing in documentation about it) was that all jobs will hold on spooling until one of the jobs completes despooling to tape and then proceed spooling further and then despooling one by one. But what if they choose to fall back to writing onto tape directly instead? This will create exactly the scenario I have encountered: while a large job is busy despooling huge backup to tape, which occupies the whole disk spool area, several smaller jobs immediately start writing to the same tape concurrently. Is it possible? Thanks, 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
