On Thu, 21 Jul 2005, Kern Sibbald wrote:
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.
We run it once per 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.
Yes, but it's not ideal behaviour as it requires that users perform a
bunch of commands when going into the changer (always a bad idea, the
machine should cope with humans fiddling, this isn't windows) hence the
other suggestion:
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.
Correct.
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).
How much of a database load does it generate to do an update slots?
"mtx status" is a _very_ fast command - even with 500 slots/4 drives
(I've done this with CD robots) the inquiry is over in less than 1 second.
Worse yet, the shop may want Bacula
to only know about 50 of those 10000 tapes.
This would be a problem no matter what the circumstances, however changers
setup like this usually have isolation rules so that only 50 slots the
reserved number of drives would be presented to the machine running bacula
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.
In this case, if the tape matches in the drive matches what bacula thinks
it should be, then why not use what bacula thinks should be the unload
slot, or assign a new one if that happens to be occupied?
Why not add an "unload drive" command, or add logic so that "unmount
drive" unloads it as well? (it's more sensible to unload it if unmounted,
in my opinion.....) ("unload drive all" could be used to park everything)
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.
Bear in mind that bacula _always_ gives explicit slot numbers to MTX
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.
what's wrong with bacula trying to catalog everything in the changer? How
much database load is there in tracking volumes?
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).
Noted.
AB
-------------------------------------------------------
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
