>> 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
