Date: Tue, 30 Jul 1996 09:52:19 -0700 (PDT) From: "Jonathan M. Bresler" <jmb> To: E00114@vnet.atea.be (Rob Schofield) Cc: freebsd-questions@freebsd.org Subject: Re: CD ROM changer Message-ID: <199607301652.JAA17793@freefall.freebsd.org> In-Reply-To: <9607291556.AA06624@atdec1.atea.be> from "Rob Schofield" at Jul 29, 96 05:56:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Rob Schofield wrote: > > I'm gonna build me a kernel, and one of the devices I have to deal with is a > 7-tray CD ROM changer attached to the SCSI host adaptor (a 1742A). I have the > bus controller device defined (ahb0? Can't remember now), and I was planning a > set of hard-wired SCSI device addresses for the SCSI system disks and this > changer. I noticed that under 2.1 I could also specify multi-LUN devices at > one address, so I thought I'd take advantage of the features of this changer. > The changer has a LUN for each disk tray. If you issue a SCSI command to a > specific LUN at the device address, then the changer automatically loads for > reading the correct disk in the tray associated with the LUN. Depending on th > SCSI command issued, it also may spin up the disk to give a "ready" status. > > So, first question: should I specify 7 devices (cd0-6) at one address in the > kernel def file, then kernel build and MAKEDEV the appropriate device entries? use a LUN for each cdrom. create the devices cd0-6 in /dev. > I have the feeling that this will cause (at boot time) the kernel to probe the > individual LUNs, resulting in the drive going through each tray one at a time > (with a total delay of some 30 secs as each one of the 7 disks spin up). This > ain't such a big deal, but here's the next Q: > > Should I be setting SCSI_DELAY to be greater than the total spinup time, the > individual disk spinup time, or use my head and suck-it-and-see (*many* kernel > rebuilds unless there's a kernel variable patch method I don't know about > yet)? I am assuming here that SCSI_DELAY is a compile option rather than a > variable assignment. try it as is without changing the SCSI_DELAY define > Let's assume I now have 7 valid devices (/dev/cd0-6) and the system has come > up OK without arguing. I now add automount statements to /etc/fstab for all 7 > devices (as -ro, CD9660) to ensure I can access them quickly as needed. Next > Q: Can I now just issue a forced "mount all" without problems? > > The scenario I imagine is that the kernel will then go through the devices one > at a time (as the mounts are performed), and assuming they mount successfully > as CD9660's, will be happy. I should observe the changer again goes through > each tray as each disk is mounted. This would mean that each disk is "ghost" > mounted (the logical device is mounted on the FS mount point even if the > physical disk is not currently loaded in the read position) and each time a > device is accessed (for a read, say), the changer will load the appropriate > disk in response to a SCSI command for that LUN. (Note, I can see a problem > here if I tried to do something as obviously dumb as trying to copy something > between two -ro /dev/cdx devices, but no-one's gonna be that dumb, right? ;^) ;) right > Last Q: since a disk takes 2-3 seconds to be loaded into read position and > then be spun up (in response to a read, say), will there be a timeout as a > result of the kernel thinking the disk isn't ready? If so, what do I have to > twiddle to allow for this the first time a disk is loaded? no need to twiddle, it just works, try it > If anyone has opinions (everyone has opinions ;) or advice/experience at this > sorta stuff, I'd be glad to hear it! my expriences are based upon a nakamichi 7 disc changer (repackaged by many vendors, kernel see it as an MBR-7 the actual messages are at home ;( ) and an ncr53c810 scsi controller jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607301652.JAA17793>