Slashdot Mirror
Ask Slashdot: Linux and IDE CD-ROM Changers
EvilNight
asks: "How do you get an IDE CD-ROM changer to work
with Linux? I know the kernel has support for these devices
but I have tried to use them in the past and have had no
luck (with the NEC 6x4). I am planning a fileserver which
needs to have the ability to serve up 20 CD-ROM discs and
I really want to use Linux for it. SCSI changers are easy
to set up (increment LUNs). The cost of SCSI changers is a
bit high though (about $190). The IDE changers are very
cheap ($85). I was looking at the Nakamichi 16x5 IDE
changer. Has anyone had any luck getting it to work under
Linux? Will the discs switch on demand or do you need to
switch them by running a command? How does it handle an
access conflict such as trying to read discs 2 and 5 at
the same time? I would greatly appreciate any advice that
you can give me."
I picked up an NEC 4x4 IDE CD-ROM a little while back, then discovered that the user-space CD control software I had wouldn't change between disks. So I wrote a program that would.
/dev/cdrom, but even a non-C-programmer should be able to figure out where to change that in the source. The error checking needs some work, too, but it *does* change discs (though it's mildly entertaining seeing it report "ioctl failed : Success" when it does).
It's pretty straightforward - it's just basically a command line interface to the CDROM_SELECT_DISC ioctl. It currently only works with
It has to be called explicitly at the moment, but I'm working on a wrapper for my MP3 player that will index the CDs in the drive and switch between them as it needs to... it might be possible to generalize that, though multiple simultaneous access to different discs would get really messy and slow...
FWIW: At a place I used to work at, they were considering a very large CD changer system (~60+ IIRC). After looking into it in greater detail, they decided instead to buy a bunch of HDDs instead and copy the CDs onto the HDDs. If you use SCSI HDDs, then multiple people can access multiple files/disks at the same time, and the overall cost (for them anyways) actually worked out cheaper. I suspect that at the prices you quoted, you wont be able to access multiple CDs simultaneously. Disk will be more expensive for you, but probably a better all-around solution.
Just do it via IDE-SCSI Emulation and it should work just like it does with a SCSI changer. It changes discs automatically. As far as conflicts go, I believe it will switch to fulfill the next request as soon as the first is complete, but don't quote me on that. I'm not a kernel/hardware wizard, but I have worked with a SCSI CD changer (Pioneer 604x) and am looking at getting a few IDE changers.
Using /dev/loop is a waste of cpu cycles. When you load the CDs onto the HD, just put each into it's own directory tree, then export the base of each directory tree via NFS/samba/etc. I've used 'cp -a' on the ones I've loaded and it's worked fine. Now admittadly I'm only exporting to other Linux and UNIX boxes.
Now if there is some reason the CD needs to be exported in it's original form, then use /dev/loop. If you need to, look in the kernel docs for where to modify parameters to increase the numbers of /dev/loop devices available. Use "dd if={cdrom drive device} of={file to dump data to} bs=16k". Then mount that file via /dev/loop. Look in the docs for CD-ROM burning for how to mount a CD image on disk. They mention how to for testing images before burning to CD.
For drive choice, go with SCSI. Pick up an Aadaptec 2940 U2W controler (plug plug, got to support the company a relative works for) and an 18G Seagate or IBM drive (quality counts). For faster serving, use multiple smaller drives in raid 0 striped fashion. Sure this is less secure against hardware failure (plain raid 0 striping gives no data integrity assurance), but it's not like you don't have backup of what's on the drives. A drive dies, reconfigure without it, and reload the CDs. When the replacement drive arives, reconfigure with it and reload the CDs. Now if you're at the point where you have 5+ drives, look at going raid 5 for the ease of rebuilding when a drive fails.
I have a NEC 6x4 that works just fine, in that I can mount any of the 4 CDs, but only one at a time. To switch discs, you have to umount, eject -c , mount. (See the man page for eject.)
:-)
A few years back I was doing systems integration for an info-on-CD-ROM company where some of the databases comprised several hundred CDs, and we had some massive jukeboxes. There were (and no doubt still are) a couple of commerical packages that made all that transparent (lets face it, the jukebox still has to go through those steps whether or not the end user is aware of it.)
The general technique was to cache (on disk) the directories of all the CDs and the first block or so of every file. The cache filesystem was "magic" and required adding drivers to the kernel (this on a SunOS box). For routine stuff like 'ls', 'find' and even 'file', just hitting the cache was all that was necessary. For a read, the cache filesystem served up what was in the cache while finding and loading the appropriate CD-ROM, so that subsequent reads came directly from it (it also did some pre-reading and buffering). Of course, if you did an lseek() you were going to have to wait. This is much simpler on a readonly filesystem (like CD-ROM), but I think they supported writeable (eg CD-RW, Magneto-optical, etc.) It also could treat multiple CD drives as part of a single filesystem. (E.g. one jukebox I got this working with had room for over 1000 ROMs and could mount six simultaneously.)
Fast, transparent access to everything on a whole mess of CDs. (Mind, if you're physically changing discs alot, i.e. you have more than the jukebox will hold, you have the hassle of rebuilding the cache whenever you manually swap discs in and out of the changer.)
Seems to me it wouldn't be too hard for some filesystem/kernel hackers to come up with something like this for Linux, at least on a level that would support small changers like the NEC.
(Just don't ever try reading from two CDs simultaneously in a changer like that -- you'll wear out the changer mechanism
-- Alastair
I've got two NEC 4x4 CD changers, and there's a reasonably :) /cdrom1, /cdrom2 etc. Works lovely. The automount
easy way to make them auto-switch CDs, despite what everyone else says.
SCSI host emulation doesn't do what you want, but
the kernel automounter (normally used for NFS)
can be told to run a command when a filesystem
is mounted, and that certain filesystems are
mutually exclusive. So mine does an eject -c0 for
eject -c1 for
man pages/docs tell you how to do it.
Yes, thats right, you too can mount all the discs in your cdrom changer at once with the /dev/changer device driver. There is a kernel patch available here for Linux kernel 2.2.9. Hopefully this driver will make it into a kernel source tree near you!