Bacula-users

Re: [Bacula-users] Tapes appearing in the wrong pool

2010-03-30 11:24:22
Subject: Re: [Bacula-users] Tapes appearing in the wrong pool
From: "Timo Neuvonen" <timo-news AT tee-en DOT net>
To: bacula-users AT lists.sourceforge DOT net
Date: Tue, 30 Mar 2010 18:20:02 +0300
"Craig Miskell" <craig.miskell AT opus.co DOT nz> kirjoitti viestissä 
news:4BB131B2.30605 AT opus.co DOT nz...
> Hi,
> I am having a slightly intermittent problem with the storage Daemon 
> thinking tapes are in a different pool from  what
> the catalog does.  Then, when the job comes to run, it hangs waiting for a 
> tape in the correct pool.
> E.g from last night, I have the following snippet of "list volumes" 
> output:
> Pool: Mondays
> +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> | mediaid | volumename | volstatus | enabled | volbytes        | volfiles 
> | volretention | recycle | slot | inchanger |
> mediatype | lastwritten         |
> +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> |       6 | ComMon2    | Used      |       1 |               1 |        0 
> |      518,400 |       1 |    0 |         0 |
> LTO4      | 2010-03-09 14:53:38 |
> |      16 | ComMon1    | Used      |       1 | 736,617,821,184 |      743 
> |      518,400 |       1 |    0 |         0 |
> LTO4      | 2010-03-23 15:44:32 |
> +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> Pool: Weekly
> +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> | mediaid | volumename | volstatus | enabled | volbytes        | volfiles 
> | volretention | recycle | slot | inchanger |
> mediatype | lastwritten         |
> +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> |       5 | ComFri1    | Used      |       1 | 754,008,966,144 |      761 
> |      518,400 |       1 |    0 |         0 |
> LTO4      | 2010-03-20 15:15:17 |
> |      12 | ComFri2    | Used      |       1 | 758,472,873,984 |      765 
> |      518,400 |       1 |    0 |         0 |
> LTO4      | 2010-03-27 15:47:27 |
> |      23 | ComFri3    | Used      |       1 | 761,428,942,848 |      768 
> |      518,400 |       1 |    0 |         0 |
> LTO4      | 2010-03-13 22:30:05 |
> +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
>
> (plus other irrelevant pools not included)
>
> and the relevant portion of the output of "status storage" immediately 
> after that:
>
> Device status:
> Device "LTO4" (/dev/nst0) is mounted with:
>     Volume:      ComMon2
>     Pool:        Weekly
>     Media type:  LTO4
>     Total Bytes Read=129,024 Blocks Read=2 Bytes/block=64,512
>     Positioned at File=0 Block=0
> ====
>
> Used Volume status:
> ComMon2 on device "LTO4" (/dev/nst0)
>     Reader=0 writers=0 devres=0 volinuse=0
> ====
>
> 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.

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?

--
TiN 



------------------------------------------------------------------------------
Download Intel&#174; 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

<Prev in Thread] Current Thread [Next in Thread>