On Thursday 21 July 2005 11:42, Alan Brown wrote:
> On Wed, 20 Jul 2005, Kern Sibbald wrote:
> > I suspect that this is because the tape is in the drive and the "update
> > slots scan ..." did not unload it.
>
> I have only ever seen that happen when things are well and truely messed
> up on the changer.
>
> > If I am not mistaken, this will be corrected by
> > the new mtx-changer script, which reports back Volumes in the drive as
> > well as in the magazine.
>
> This brings up another small problem:
>
> We're currently using 'update slots' to park all tapes prior to opening
> the changer, in order to avoid people loading tapes into slots used by the
> tapes in the drive(s) (I can work out how to avoid the appropriate slots,
> but this needs to be foolproof for average users who won't look)
That's interesting, but I don't see why "update slots" will park all tapes,
because it unloads only the one drive that is concerned. If there are
multiple drives, any tapes in the other drives will stay loaded in the drive.
>
> A "park all tapes" command is going to be needed, preferably inside bacula
> so the system knows that the tapes are no longer in the drive, or possibly
> an "idle autoloader" command to do the same thing. (and an "unidle
> autoloader" after the event)
This is possible, but it is not currently something that Bacula does. It
seems to me that it is not very hard write a script that does this that pokes
the appropriate commands at bconsole.
>
> Alternatively (and probably better from a user operations point of view)
>
> Allowing people to load slots randomly is fine from the changer point of
> view - almost all changers (and I believe MTX) simply put the unloaded
> tape into the next highest available slot (with wraparound) if the slot
> the tape was taken from is full, however this will result in Bacula errors
> next time the tape is loaded, as it'll be taken from the "old" slot.
Yes, if users load tapes into slots that have a tape X in a drive, then the
next time that tape X is unloaded, as you note, it will go into the wrong
slot (from Bacula's point of view), then worse, the next time the tape X is
requested, the wrong one will be pulled up. If I am not mistaken, Bacula
will then mark the tape X as not being in the changer.
Perhaps at that point, it might be reasonable to do a "update slots". The
problem is that this would need to be put under some sort of user directive,
because you can imagine the chaos if Bacula initiates an "update slots" on a
robot containing 10000 tapes (actually, I think Bacula handles 5000 slots
maximum). Worse yet, the shop may want Bacula to only know about 50 of those
10000 tapes.
>
> Given "update slots" will no longer force unloads, is there any reason why
> it can't be run before all loads and after all unloads, in order to
> mitigate effects of humans fiddling? (Doing this means that nothing
> special has to be done in order to open the changer for tape swaps, AND
> that there is no need to wait until all jobs are finished and all drives
> are quiet.)
At the current time, "update slots" still forces an unload of the device it
gets attached to (the first one available in the autochanger). For the
moment I have decided not to change the logic. This is to avoid the problem
that I saw with one user where the changer lost track of what tape (slot) was
loaded, so the report was incorrect. Unloading it causes the report to be
correct.
>
> There is one more issue which I've realised today - if the changer is
> power cycled, details of what the home slot is for a particular tape in a
> drive are lost. At that point, MTX unload will unload to slot 1 unless
> explicit arguments are given.
Yes, this is what I mention just above. My autochanger does remember what
slot a volume goes in even after a power cycle, but I think that most do not.
>
> Getting into the realm of extra functionality, if bacula is hanging
> waiting for a particular tape or more tapes to be added to a pool, perhaps
> update slots can be run each time it retries the job, in order to see if
> the tape has been added into the changer?
This is a good idea, but again, it depends on two things: 1. not unloading the
drive (well this is not catastrophic in this situation) 2: the user can
specify exactly what "update slots nnn-mmm" command is executed to prevent
Bacula from trying to 'catalog" everything.
By the way, in version 1.37 for "update slots" to work, you *must* add the
new Autochanger resource in the SD conf file, and you *must* have a
"Autochanger = yes" in the Device resource(s).
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
