On Sunday 09 September 2007 06:27:50 pm Ivan Adzhubey wrote: > Hi Kern, > > First of all thank you for your efforts on confirming and fixing this nasty > bug! Now at least I know it was not something I did wrong in my > configuration (I have struggled with multiple simultaneous jobs spanning > several volumes for quite some time, as you can see from my earlier posts). > > Since this is obviously a major bug I hope you won't mind providing a few > clarifications, as soon as your time permits. Please, see my questions > below. Of course, releasing the fix as quick as possible is of most > importance, so I will be patient. > > On Sunday 09 September 2007 05:46:24 pm Kern Sibbald wrote: > > Hello, > > > > I regret to have to announce that there is a rather serious bug in > > Bacula. > > > > Bacula bug #935 reports that during a restore, a large number of files > > are missing and thus not restored. This is really quite surprising > > because we have a fairly extensive regression test suite that explicitly > > tests for this kind of problem many times. > > > > Despite our testing, there is indeed a bug in Bacula that has the > > following characteristics: > > > > 1. It happens only when multiple simultaneous Jobs are run (regardless of > > whether or not data spooling is enabled). > > Does this mean that the bug only shows up if you actually *run* > simulatneous jobs or even if you just have them enabled in config? I mean, > after struggling with solution for this problem myself, I finally worked > around it by fine-tuning job priorities in such a way that only small jobs > (guaranteed to fit a single volume) are allowed to run concurrently, while > large jobs each have a priority set to a different higher level so only one > of them could run at a time. I suppose I should be safe with that > configuration? I hate if I'll need to drop all of my backups, I have just > finished backing up about 8TB of data...
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... --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
