Hello, Le vendredi 30 avril 2010 15:16:56, Jake Scott a écrit : > Hi Kern. > > I'll take a look at the developers guide and get back to you, thanks for > the pointers. > > >> The features that I'd like to work on are : > >> - Automated configuration of storage devices in a library (using > >> > >> serialization) > > > > It would be nice to have automated configuration of storage devices, but > > unless you have some trick, it is generally quite system dependent, and > > we try as much as possible to avoid system dependent code. In addition, > > storage configuration at all but the very largest sites is generally > > done once in about 10 minutes when initially installing Bacula. > > Most modern libraries can return the list of drives they have along with > their serial numbers. You can then match the serial numbers up with the > results of a SCSI device probe and auto-configure the whole lot (including > auto-detection of the device type with help from the inquiry strings). > > Even with a single host, a library with more than a couple of drives > becomes hard to configure as you need to know which drive index maps to > which local device before hand. When you share devices amongst hosts this > is gets very error prone. Also your device numbers sometimes change which > means you need to reconfigure manually -- if you have an automated method, > this is less of a headache. I'll dig into the library query details to > see how easy all this is..
To resolve this problem, I'm using udev with some very simple rules based on the serial number, the model or the scsi ID, and it fixes the device name in /dev. As you said, using fixed device name is very important when having multiple scsi cards, drives, etc... > >> - Support for native Linux changer device (more robust that MTX in my > >> > >> experience) > > > > If it requires Bacula to send SCSI commands to the control channel, then > > it is very unlikely we would accept the code. It is much better to have > > such highly dependent system code in a separate program. If you can > > write better code than MTX, it might be worthwhile creating a new > > program. If Linux has some simple way of working an autochanger that > > can do everything that MTX can in the same simple ways that MTX works, > > that could be interesting. > > My limited experience of MTX is that its very very unreliable. For > instance, my box here sometimes tells me that I have 2 drives and 45 > slots. Other times it does the right thing and returns 6 drives, 45 slots > and 12 mail slots. Interesting, I had problem one time with a StorageTek L180, but I was a problem with the autochanger BIOS, once updated, it worked fine. I suppose that it depends on the hardware that you use. What is your autochanger model ? > Try 'modprobe ch'. That'll give you a /dev/sch* device. The utilities > are available from http://linux.bytesex.org/misc/changer.html. 'mover' > uses /dev/sch*; I've seen this to be much more reliable using several > types of changer. Same with FreeBSD and its native changer device. I > think Solaris has one now too.. In this case, this is a replacement for mtx-changer script, that can be call mover-changer or something like that, very interesting for users that have problems with mtx. Bye -- Need professional help and support for Bacula ? Visit http://www.baculasystems.com ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
