>> So the catalog thinks ComMon2 is in the Mondays pool, and the storage >> daemon thinks it's in the Weekly pool. Does the >> pool info get written to the tape itself? I'm about 90% sure that ComMon2 >> has never been in the Weekly pool, but this >> is my first deployment, so stranger things might have happened along the >> way. >> >> If there's no pool info on the tape directly, then where is it getting >> this erroneous idea from? I'm happy to file a >> bug if it truly is one, but want to be sure I'm not missing the obvious >> first. >> > > I may be completely mistaken, but I think pool info is only in the catalog, > and for director's use only. I think SD would care about volume names/labels > only. So, that "pool" line in SD's status might be (dis)informational only, > though it does look incorrect... Volumes may be moved between pools (like > move to scratch pool after purge) anyway, with no need for the physical > volume to be accessible. That was my expectation too, and I think I have an answer now; from the source, the status of the device uses a pool name for the device, which is only updated when the device is reserved (i.e. a job actually starts on that device). If a new tape gets inserted and mounted, the device will still report the previous pool until a job that needs to append to the device. I think this counts as a bug (even "*unknown*" would be a better report than the wrong pool), so I'll file a report.
> What I'm wondering, is that ComMon2 has status "used" (like all the volumes > you listed) together with the strange count of VolBytes=1. So, could this be > the reason why Bacula is waiting for another (appendable) tape? The last time that tape was used, the job failed; it had started writing, but then something went horribly wrong (can't recall what), leaving it in that state. I think you're correct that the pool name is a side-issue. Thanks, Craig ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
