[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
> drive nnn
If you ask "where 10" you will have
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
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.