> > 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?
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>
> 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)
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)
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.
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
