[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Remaining dual changer problems


On Saturday 24 May 2008 15:08:19 Kern Sibbald wrote:
> Hello Eric,
> I assume that since I haven't heard anything from you that the last fixes
> (2.2.10-b4) to the reservation system, fixed the problems you were having.
> For others on the list, the company Eric works for runs 270 nightly jobs so
> they have a tendency to run into Bacula SD bugs.

Yes everything is ok right now.

> There still remains one outstanding problem of which I am aware that
> fortunately is not hitting you, and that is bug #1083 "SD attempts to load
> volume already loaded in another drive for multi-drive disk autochanger".
> This bug shows up only during swapping of a volume from one drive to
> another and typically is created when PreferMountedVolumes=no.
> I know what is causing the problem and after thinking about different
> solutions, I think the best one is to add a new autochanger script query.
> For memory the current commands are:
> #  The commands are:
> #      Command            Function
> #      unload             unload a given slot
> #      load               load a given slot
> #      loaded             which slot is loaded?
> #      list               list Volume names (requires barcode reader)
> #      slots              how many slots total?
> #
> The new one would be "where" and would be called
>   mtx-changer "changer-device" where "slot-number"
> the other two arguments would be ignored.  This new function asks where a
> Volume with "slot-number" is located.
> The answer can be:
> slot nnn
> or
> drive nnn

If you ask "where 10" you will have
slot 10
drive 1

ok, or we can change the "load" function to do the work.

load drive0 slot1
 - check if slot1 is already loaded (do nothing if already in drive0)
 - load the slot1 to drive0 if slot1 is unloaded
 - exit with error code 1,2 or 3 and with a message "already loaded 2"

And we have to handle the third case in the SD.

> This command would be issued before each load request, and if the Volume is
> already in the correct drive, nothing more would be done; if the volume is
> in its slot, it would be loaded; and if the volume is in a different drive,
> it would be unloaded, then loaded into the desired drive.
> This would allow a simple interface for the SD to ensure that it takes the
> right action to load a particular slot in a particular drive without the
> need for trying to track it within the SD.  For me it makes the most sense
> because it is the changer device that definitively knows where the volume
> is.

It makes sens and will simplify the code, it's just a bit strange to loose 
volume location across the code, but i know that it's a very complex part
of the SD.

> Aside from wanting feedback on this idea, the big question is when to
> implement this.  Clearly it should be done before the next major version as
> it will allow us to eliminate a class of annoying little problems.
> I am also considering the possibility of implementing it in Branch-2.2, but
> I really don't like that idea too much because it means that it will break
> all the autochanger scripts implemented by users (at least one virtual disk
> changer and the FreeBSD chio based script).  In any case, it is *very*
> unlikely to be implemented before the 2.2.10 release.

I'm agree with you, changing the mtx script during a 2.2.X release is not a 
very good idea, but if the changelog and the error message is clear, i think 
that it can be done.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.