From owner-freebsd-hackers Fri Feb 20 16:05:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03671 for freebsd-hackers-outgoing; Fri, 20 Feb 1998 16:05:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from thunderdome.plutotech.com (root@thunderdome.plutotech.com [206.168.67.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03582 for ; Fri, 20 Feb 1998 16:05:17 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by thunderdome.plutotech.com (8.8.7/8.8.5) with ESMTP id RAA19707; Fri, 20 Feb 1998 17:05:07 -0700 (MST) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id RAA24110; Fri, 20 Feb 1998 17:05:05 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199802210005.RAA24110@panzer.plutotech.com> Subject: Re: CD-ROM filesystems / read ahead / caching... In-Reply-To: <34EDC9B3.AAF5A8AC@tdx.co.uk> from Karl Pielorz at "Feb 20, 98 06:21:39 pm" To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Fri, 20 Feb 1998 17:05:05 -0700 (MST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karl Pielorz wrote... > Is it possible to set read aheads / caching parameters for cd9660 file systems > / mounted CD's under FreeBSD? > > I have 2 x 7 CD-ROM jukeboxes which I mount (and share out via samba) - with > the usual 'thrashing' that occurs when 2 people go for 2 CD's on the same > drive but in different changer bays... > > I don't expect the file systems to do anything like delay reads to the second > LUN until the 1st one is finished (after all, how would they know that without > nasty time-outs etc. :-) - that's a bit beyond the scope of a fs I guess... > - But I don't mind 'wasting' memory on say caching data, or setting very > large read-aheads (e.g. 128k/256k). Interesting you should bring this problem up. :) I am almost done with some code in the CAM CD driver to solve exactly that problem. Lars Fredriksen was nice enough to send me his 7-CD changer so I could get this code working. Basically, the code as it is now sets up mutually exclusive access to each disc in a changer. i.e., while one disc (lun) is active, commands for other luns/discs are queued and not sent to the drive. Thus the changer won't switch so often and thrash. I have low-end and high-end timeouts that are configurable. The low end timeout sets the amount of time that a particular lun *must* be given, and the high end timeout sets the maximum amount of time a lun will be allowed to take if there is other I/O waiting. I am working on a method to calculate and factor out a changer's change time from the minimum and maximum timeouts. Changer detection is done more or less automatically -- if a CD device shows up on a lun greater than 0, it is considered to be part of a changer. Every lun on that device is then marked as part of the changer, and each lun is put in a special changer queue system. I do have provision to specify quirk entries for devices that should not be treated as changers. I will hopefully have this code in the next CAM snapshot, so you can test it out and see if it helps with your problem. (If you're willing to run -current and CAM, that is.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message