On Wednesday 07 February 2007 11:52, Alan Brown wrote: > Version: 1.39.34-1 + 2.0.1 spooling patch(privately supplied by Kern)
I recommend that you update to 2.0.2. For you it is an easy upgrade, and somewhere in 1.39.x I fixed a "number of files mismatch" related to FDs failing (disconnect, crash, ...) as well as a race condition in the schedule. > > Mysql 4.1.20 (but I don't think this matters overly) > > > It looks like there's a database race somewhere, as I'm seeing stuff like > this every 2-3 days when a bunch of concurrent and simultaneously > scheduled jobs are running: The above cannot be quite true since the tape is in the process of being "opened". There may be a number of jobs queued to run, but only one job is actually running unless they are using another drive. Please upgrade, and it it still happens, you will have to be a lot more precise as something this complicated is impossible to debug without being able to reproduce it or knowing *exactly* what triggers the problem. Regards, Kern > > > 06-Feb 22:34 msslay-sd: Volume "AHIG0017" previously written, moving to end > of data. > 06-Feb 22:34 msslay-sd: Cluster-common.2007-02-06_22.30.00 Error: I cannot > write on Volume "AHIG0017" because: > The number of files mismatch! Volume=1 Catalog=0 > 06-Feb 22:34 msslay-sd: Marking Volume "AHIG0017" in Error in Catalog. > 06-Feb 22:34 msslay-dir: Cluster-common.2007-02-06_22.30.00 Fatal error: > > Other Concurrently started jobs on the same volume finish OK and finish > after the error is logged. > > This only happens when there are several jobs concurrently using the same > volume and only seems to happen when the jobs were all started > simultaneously (ie off the same schedule). > > The "number of files mismatch" can happen with any number of files > on the tape (I've seen it at ~200-201 for instance) and I've seen the > Volume vs Catalog difference go as high as 3 files. > > > Possibly related: > > > I've also occasionally seen jobs using the same pool ignore a volume > already in use by other concurrent jobs and load up another (purged) > volume from the pool - This is irritating: > > I have "Volume Use Duration = 7 days" on all tapes (after that they go > into the data safe) and it sometimes results in 200Gb LTO tapes being > marked as "used" with 40Mb (or less!) of data on them. > > It can result in bacula recycling and then demanding a tape which is not > in the changer when there's plenty of space on an existing appendable > volume. > > This only happens when there are more than 3-4 jobs running on the same > pool and happens despite "Prefer mounted volumes = yes". > > Is it possible that this behaviour is related to maximum concurrent jobs > for each drive within the changer? (I have these set to 10 for the changer > and 5 for each drive if addresses individually) > > > I can't see any mention of this in the Changelog, so I assume the > behaviour is still there in 2.0.2 > > > Is anyone else seeing this behaviour? > > Kern, is this a bug? > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
