Date: Fri, 20 Feb 1998 17:05:05 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: kpielorz@tdx.co.uk (Karl Pielorz) Cc: hackers@FreeBSD.ORG Subject: Re: CD-ROM filesystems / read ahead / caching... Message-ID: <199802210005.RAA24110@panzer.plutotech.com> In-Reply-To: <34EDC9B3.AAF5A8AC@tdx.co.uk> from Karl Pielorz at "Feb 20, 98 06:21:39 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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... > <g> - 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802210005.RAA24110>