I have no experience with optical jukeboxes with Linux!!!! I have had experiences with Optical jukeboxes under HP-UX. In this setup the the jukebox had a SCSI address of it's own. Each slot in the jukebox had an associated LUN number. A device name was assigned for each disk slot A side and B side. The mount command was run against the appropriate device name. I had a jukebox with just one drive and 16 optical disk slots - 20 Gig. I thought it was going to be a real hassle to write a disk mount manager to share this drive among users until I discovered you can mount as many disk as you want and the jukebox driver takes care of arbitration - what a nice feature. Granted, you only want archive type data here and your overall system configuration to be such that not too many processes will be accessing the jukebox at the same time. The disk spin down, carriage load, carriage move, carriage unload, carriage move to the next disk, carriage next disk load, carriage move, optical drive load, and spin up takes about 12 seconds - "seek-from-hell".
Hi, I was reading your howto (a life saver, thanks) and I was wondering what kind of jukebox you were running? I have a Maxoptix 520 Jukebox (20 disks at 2.6G each, nice!) and I would like to connect it to a Linux box and serve the drives up to my users, but I'm having problems accessing the individual drives. Currently I can only access the two drives and something called MAXLYB which I think is a controller device of some sort. Basically, I'm wondering if the jukebox you had was the same or similar and how you set it up. I know that you did it under HP-UX, but any help right now would be nice. Hey, I'll even let you log into my linux server if you want to take a look at the jukebox and see what it does. You can't beat 52Gig of storage! Anyway, I'd really appreciate your help. Zed A. Shaw Application Systems Analyst Arizona State University
> It sounds like your Maxoptix 520 is a jukebox with two physical disk. Yep, that's the one. > > All jukeboxes have a carriage controller. This is probably your MAXLYB > device. > ... What I've come to find out is that Maxoptix is pretty stingy when it comes to drivers. Apparently, they don't make driver software for any of their Jukebox carriage controller interfaces! I don't know how some of these companies stay in business. I'm going to pester them again soon, but you are right, this thing will need a carriage controller driver to operate. The cool thing is that this MX520 (that's the model number of the juke) emulates a whole slew of other carriage controllers, so maybe one of those other guys has a driver. I'll be looking into that too. > > You might want to get a-hold of Maxoptix and see if they have a install > package for your linux kernel version. If not ask them for the programmers > specification for the carriage controller and maybe we can write one! > Hey, if I can't find any driver software, and I can convince Maxoptix to give me the specs, I'd be more than glad to write a driver. I'd could sure use the help too since I haven't got enough time to do it on my own. Also, do you know of anyone else doing this that we might be able to hack off of? > Any information you find, let me know and we will roll the information > into the Optical HOWTO, acknowledgments of course! > Sure, but let me get some new information first. So far things are looking pretty bleak. > > >Basically, I'm wondering if the jukebox you had was the same or similar > >and how you set it up. I know that you did it under HP-UX, but any help > >right now would be nice. Hey, I'll even let you log into my linux > >server if you want to take a look at the jukebox and see what it does. > >You can't beat 52Gig of storage! > > Nice. At home I can use PPP to mount my 84 platter HP-UX jukebox. > It's slow though - I wish I had it at home. Oh, I don't have this thing at home. There's no way I could afford the $30,000 my boss paid for this thing. But he's stuck with it and has had it sitting around collecting dust for a year, so he's letting me play with it and try to find a use for it. I'll get back with you when I have some more information. It should be sometime this week when I find out if I can get it to work or not. Zed
Skip Please find some guff on MO drives and SCSI agony ... Note that the Changer software mentioned should work for virtually any changer :-) Now back to dreaming of cheap highbandwidth inet connections for home use. British Telecom really get on my !"£***& Cheers Jon Gerdes Some notes on firing up SCSI changer support for a Magneto Optical jukebox using "scsi-changer" ============================================================== LSM entry from distribution used: Title: scsi-changer Version: 0.14 Entered-date: 9 May 1998 Description: SCSI Media Changer device driver (for the robot mechanism of MO/CD Jukeboxes, tape libraries, ...). autofs support included. This is a BETA version. Keywords: scsi jukebox changer driver Author: Gerd Knorr <kraxel@cs.tu-berlin.de> Maintained-by: Gerd Knorr <kraxel@cs.tu-berlin.de> Primary-site: sunsite.unc.edu /pub/Linux/kernel/patches/scsi 22kB scsi-changer-0.14.tar.gz 627 scsi-changer.lsm Alternate-site: none Original-site: none Platform: Linux Copying-policy: GNU GPL =============================================================== Latest version from here: http://www.in-berlin.de/User/kraxel/linux.html Tested on: HP SurestoreOptical 40fx (1 drive 15x2.4Gb MO disks) Adaptec 1520B (dodgy ISA 10MBs-1 SCSI II card) Linux Mandrake 6.1 Kernel 2.2.13 and 2.2.14 tar -xzvf changer-0.14.tar.gz read the README Note that this program should work for most SCSI devices involving a robotic picker and media slots. patch kernel: copy ch-2.2.7.diff to /usr/src/linux (ie kernel source) patch -p1 < ch-2.2.7.diff Compile in changer support to kernel: make xconfig or menuconfig or just config go to scsi section and tick changer support put in NFS and automounter (see below) while you are at it. If your using it as a module then add this to /etc/conf.modules: alias char-major-86 ch (no problems found using it as a module - recommended method of use) run /usr/src/linux/drivers/MAKEDEV.sch (created by .diff) to create the changer dev entries, one for the changer and one for the reader if you have more than one reader, you will need more /dev/schx's (see <src>/Documentation/devices.txt - again added by .diff) Run make in the changer source directory I had to copy scsi_ioctl.h to changer source directory and amend the Makefile. Not sure why, so read and change the Makefile if compiler gives errors about such a file not found (find /usr/src/linux -name <file_to_find> might be handy) copy binaries to /sbin (or /usr/sbin or whatever to taste) mover load 0 fdisk /dev/sda (create sda1) mke2fs -b 1024 /dev/sda1 1273011 mover unload 0 mover load 1 fdisk ... etc "mover mv d0 d0 1" will rotate disk in drive 1 etc etc fdisk was OK but mke2fs had problems determining the correct geometry. the number of blocks came from dmesg report hence specifying everything explicitly - your milage may vary. The block size was printed on the disks as well as from "dmesg" The above is crying out for a quick script to shuffle through the lot. mover without switches will show the contents of the box. make sure that scsi supports > 1Gb on Adaptec 1520B - aha152x needs (in /etc/lilo.conf): append="aha152x=0x340,10,7,1,1,0,100,1" check source for meaning of parameters. I also had a weird problem where the adaptec driver appeared to caused Lilo to forget much of the append= line - pretty esoteric but it may afflict someone else. I had a Frame Buffer init string in there as well and after swapping these around (ie SCSI bit first then the video bit it worked) The adapter BIOS had to be adjusted slightly in the CTRL-A menu on boot to also enable extended translation. If the geometry is wrong then mke2fs will attempt to access incorrect addresses. This causes the kernel to go absolutly mad, printing lots of errors to the root console and filling up the system log. I had to use shift-alt-sysreq-b to re-boot after synching disks, when I got it wrong :-( My console was totally unusable with hundreds of messages scrolling up it. So if this might happen to you, make sure that the "Magic Syskey" is enabled (see kernel docs.) Alternatively do it in X from an xterm, that way you can kill the job from another one ... Now dig out the automounter (instructions in README). The devices are /dev/sda1 and /dev/sdb1 (or similar) not the /dev/schx jobs. Remember to have automounter and nfs support in the kernel. Attempting to cd /jukebox/0 will get the jukie to dig out the first disk and pop it into a spare drive and even mount it. Not sure what the problems I had were actually caused by. On boot the devices were found and reported correctly but mke2fs wasn't going to play. I even managed to wreck one side of my first MO disk so that even fdisk refuses to play. You have been warned <g> Still I do have a ridiculously large amount of filesystem space to play with at home. Incidently, if you put a FAT f/s on a disk and leave it in the drive, then Win98 can read it, if you happen to dual-boot (pah !) Check the contents of the .diff file and the source itself - the author has been pretty thorough with documentation. Performance is not blistering but beats the heck out of a CDRW. Finally, thanks to Mr Knorr for giving me an endless file system Jon Gerdes - 17 January 2000 mailto:jon.gerdes@virgin.net
Hi, I have the ANSI SCSI-II specs. Changer devices are described here. Basically, changers are independent devices which respond to commands like: Install disk in slot 7 in drive 2 Remove disk from drive 1 and store it in slot 13 Count all disks in the slots and so on. Btw. the SCSI specs make no differences between tape changers, od jukeboxes, cd changers. These are all changer devices with the same command set. The jukebox running under HP-UX seems to work differently from the SCSI specs, where no LUNs for the slots/sides are defined. Three possibilities: 1. LUNs for the disk sides are defined in SCSI-III specifications (I don't know because I do not have them) 2. The jukebox and its driver is older than the SCSI specs, so the manufacturer had to go its own way. This is the way my jukebox works, but in my case the commands are similar. 3. The manufacturer choosed to ignore any specifications Long time ago I have tried to make my jukebox work with linux. It worked with the generic scsi driver /dev/sg*, some lines of C and a handful of shell scripts, but I did not have the time (and knowledge) to build a real kernel module from that. There is still another problem: One has to write a new filesystem type for write-once media. The ext2 filesystem can not be used because it writes superblocks all over the disk and modifies them when data is written to the disk. Sectors which have been written to are definitively lost. They can be overwritten but in fact the new data is written to spare blocks and the old data is discarded. This old data can be retrieved with special commands for optical drives. There must be some kind of "append-only filesystem" to make it really useful. Greeting Michael Heydenbluth mh@heywei.de