On Thursday 13 April 2006 16:51, David Boyes wrote:
> > > Kind of a misleading name, though. It's really a volume state
>
> indication
>
> > > -- eg, the volume is mountable or not.
> >
> > In its current usage, I find it to be the best name. It indicates if
>
> the
>
> > volume is in the changer or not.
>
> It does work, but I think it reflects an assumption born of Bacula's
> history -- that we're dealing with relatively small libraries that are
> dedicated for this purpose. As we grow into the enterprise space, it's
> probably not a good assumption to make long term.
>
> For example, one of our 3494s has 15K+ volumes physically present. Not
> all of those volumes may be available for use -- but they are still
> physically in the library unit. What would InChanger mean in that
> situation?
Normally, Bacula would not have any knowledge of Volumes that it cannot use.
If a volume is temporarily not available in the changer, simply setting
InChanger=0 will keep Bacula from accessing it providing there are are
sufficient other volumes available. If you really want to keep Bacula from
using the Volume but indicate that it is in the changer, leave InChanger=1,
and set the Status to something like "Disabled" or "Archive".
Everything that one needs to indicate what you want above is already in
Bacula. That is not to say that it cannot be improved or extended, but I
don't see any false assumptions ...
>
> It's not critical to the discussion at hand. It's more of a "think about
> this for the future" comment.
>
> > This shouldn't pose any problems.
> >
> > > We redefine InChanger to be VolumeState (or add a VolumeState
>
> variable
>
> > > and transiton to it over time).
> >
> > I'm not sure I want to change InChanger. Every change to the database
>
> is
>
> > extremely painful for me, particularly because of SQLite which does
>
> not
>
> > have
> > ALTER TABLE -- it requires hours of work involving minutia.
>
> <grumpy> Ugh. Not to be rude, but that sounds like a good reason to just
> toss it and require a real DBMS for Bacula. In these days of good cheap
> packaged DBMSes, is it really worth the headache to deal with SQLlite?
> How tough is 'apt-get install mysql'... pleh.
>
> Never mind. Not relevant to this discussion. </grumpy>
Yes, I agree, but eliminating SQLite would probably cut Bacula's usage or
testing for adoption in half.
>
> > What would the new values for InChanger (or VolumeState) be?
>
> Offhand, how about this:
>
> 0 Unavailable (for whatever reason: missing, broken, lost)
> 1 MOUNTABLE (the equivalent of today's InChanger=1)
> 2 NOTMOUNTABLE (may still be in the changer, but administratively
> unavailable waiting for pickup)
The above three states I can clearly see. Though #2 is not really needed as
it is embodied in the Status column.
> 3 COURIEROUT (picked up by courier and in transit to offsite
> vault)
> 4 VAULT (confirmed arrived and checked in at offsite vault)
> 5 VAULTRETRIEVE (ready/eligible to return from offsite vault)
> 6 COURIERIN (picked up by courier and in transit back to you)
> 7 ONSITERETRIEVE (arrived onsite, but not yet checked back into
> library)
It seems to me that the above states (3-7) are really locations and that they
might better be handled through the Location table. If this is not the case,
then what is the purpose of the Location table?
>
> States 1-7 are a progressive cycle (eg, 1->2, 2->3, ... 7->1). States 0
> and 1 should map directly to the current InChanger usage. The
> distinction between "unavailable" and "not mountable" will be important
> for copypools -- we need to distinguish between "the volume is
> permanently gone" from "the volume is not online or directly available".
>
> Note that the meaning of the courier states and the vault state (in
> terms of the location of the vault and the identity of the courier)
> would be defined separately (vault defined by one of the location
> values) and we'd need to come up with a way to specify courier
> information, but I think that falls into the province of the DR manager
> that Arno's discussed.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
