Hello,

03.09.2008 18:43, Brian A. Seklecki wrote:
> Back in late `05, early 06 I recommended changing the the barcode
> handling to abstract the "volume id" from the "bar code" value.  I'd
> like to re-propose that.
> 
> The current barcode system only allows you to label your pool members
> using 1) the serial as a suffix 2) a pre-defined prefix.
> 
> We prefer to use the "Volume ID" as a symbolic name "Week0, week1,
> week2...week 52..." for example, in pool "OffSiteWeekly", to simplify
> volume management and off site storage.
> 
> For example, we have to keep track of:
> 
>   chio -  volid  - bac-slot - tape ser - storage ser
>   ------------------------------------------------
>   slot 0 = Daily6 = slot 1 = 000123 = xxxxx027
> 
> Tape serial and storage vendor serial (what the scan when they move
> media offsite) are organizationally unique IDs.  However, the Bacula
> volume ID is relative.
> 
> There's no reason Bacula couldn't have a serial-number column in the
> volume table (by which chio(8) or mtx(8) ask for the volume) -- separate
> from the "relative" volume ID.
> 
> You could maintain a strict 1:1 relationship initially.  That would
> avoid schema changes.  However, that would also prevent you from
> tracking tapes that have been destroyed, etc. (Media volume management)

Well, as I still intend to create a volume management add-on to Bacula 
(the needed tables already exist in the catalog...) I think your idea 
is reasonable.

> Therefore, to normalize the SQL pragmatically, you'd have to create a
> separate table "PhysicalMedia", and a pivot table to relate physical
> media to volume (with an "active flag").  
> 
> E.g., Over the life of a system, you might have 20 tapes that function
> as "Daily2"

Personally, I wouldn't like that, but that's probably a matter of 
taste. I like the meaningless volume names :-)

> The "in changer" flag would move along with the "Physical Media" table.
> 
> In the Dir, when a pool/VolumeID selection has been made, another query
> is made in the pivot table for the current "active" physical media for
> that Volume ID -- and MTX loads that unit instead.
> 
> Thoughts?

Probably rather easy to implement, though it will require user 
interface changes and might thus break existing add-ons that use 
bconsole as the interface to Bacula.

Much of the volume handling in the protocol between DIR and SD should 
be abstracted enough to not require a major redesign.

But, as the current way to handle volumes works quite reliable, I 
suppose Kern would not see the need to implement this. If such a 
project was discussed with the developers and users, and no serious 
objections arise, a patch would probably be accepted. Only someone 
would have to do the actual work...

Arno


-- 
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users