Date: Mon, 29 Jul 1996 17:56:18 +0200 From: <E00114@vnet.atea.be> (Rob Schofield) To: <freebsd-questions@freebsd.org> Subject: CD ROM changer Message-ID: <9607291556.AA06624@atdec1.atea.be> Resent-Message-ID: <vines.mmb7%2BOuBzlA@vnet.atea.be>
next in thread | raw e-mail | index | archive | help
Comments By: Robert Shofield@6-30 TGO@ATEA_6-00 Originally To: smtp[questions@freebsd.org] Originally From: Robert Shofield@6-30 TGO@ATEA_6-00 Original Date: 25/7/96 13:49 Comments: This is a re-post; I have inadvertently sent the original to goodness-knows-where, so my apologies if I waste bandwidth.... ======================================================================= Thought I'd just toss this one on the log pile. 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 the 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? 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. 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? ;^) 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? If anyone has opinions (everyone has opinions ;) or advice/experience at this sorta stuff, I'd be glad to hear it! -- Happiness is a smoking processor....... Rob Schofield M.Sc. AMIEE schofiel@xs4all.nl http://www.xs4all.nl/~schofiel -------------------------[Original Message]-------------------------- Thought I'd just toss this one on the log pile. 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 the 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? 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. 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? ;^) 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? If anyone has opinions (everyone has opinions ;) or advice/experience at this sorta stuff, I'd be glad to hear it! Thanks! -- Happiness is a smoking processor....... Rob Schofield M.Sc. AMIEE schofiel@xs4all.nl http://www.xs4all.nl/~schofiel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9607291556.AA06624>