Date: Tue, 9 Jan 1996 06:05:33 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.org Subject: Re: Good News :) Message-ID: <199601091105.GAA25461@hda.com> In-Reply-To: <199601090716.IAA09073@uriah.heep.sax.de> from "J Wunsch" at Jan 9, 96 08:16:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I've burnt my first CD today! > > > > > > Well, i sorta mis-burnt two of them, but the first step has been done. > > > > Details on the tools you used, please. And did you do it single > > user or multi user? > > This was just the proof-of-concept stage. > > The tools were scsi(8) (actually, a bunch of them -- thanks, Peter!) > and team(1), wrapped together by a Perl script. > > Using dd(1), the burner starved immediately. With team(1), it looks > better. You can run enough processes pre-reading data from the disk, > thus caching it in memory. This was running in ``slight multi- user'' > mode, i.e. multi-user stage with just a single user logged in, no X11, > no heavy background tasks. I forgot to raise the process into rtprio, > however. While the first attempt went through but rendered me with an > unusable disk since i've totally misunderstood team's man page, the > second one starved after burning about 50 MB. The CD is mountable, > the directory structure is intact, but it experiences lotta errors > when reading most of the files. Anyway, the ~ 50 MB are way more than > the machine has RAM, so it's still proving that it can be made work. Eventually I'd like the system to schedule I/O requests based on the rtprio priority. I have a scratch kernel around that prefers rtprio requests to normal ones. It makes xcdplayer snappy. One problem with scsi(3) and therefore scsi(8) is these don't use the start queue and so you'll get the latency to resume each process even with a "team" approach to running scsi(8). I assume you're doing some combination of scsi(8) scripts to setup then some "team" dd incantations to transfer the data to the CD-R? > Burner and source disk are on different SCSI busses, but i'm not sure > if this is really necessary. It's just the configuration of that > machine (one bus for the dis[s], another one for the slow peripheral > devices). > > The bad news is, manufacturers of CD burners disagree about the > command set. My experiment ran with a ``Plasmon Data RF4100'', and > with some minor hassles (downloading from an US BBS via transatlantic > phone lines, ick) i could get their SCSI manual. Judging from Linux' > cdwrite, most burners seem to be only slightly different in the > command handling, with the major exception of Yamaha. They do just > everything different. So when stuffing all the invocations of scsi(8) > back into the kernel, i'm thinking of an lkm-based interface, where > the actual CD-R handler must be plugged in as a loadable module. But don't forget some people may have more than one CD-R, though I don't know if they'll need more than one "personality" loaded at once. The scsi code can accept user defined types loaded via an LKM. If you wanted to do it your way you could have the base code in the kernel as a WORM type and then LKM in support for specific devices that use the WORM code as a library. We do have to clean up that conf code to make this work cleanly. An aside - one thing I'll point out is it would be easy to hack scsi(8) to spit out a C code interface for one of its command strings. I don't know if that is of interest or not. > Who is interested in dicussing further issues of the concept (once > i've got further)? Should i do this in this list? If no one else chimes in we'll take it off line. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601091105.GAA25461>