From owner-freebsd-scsi Thu Oct 3 03:23:37 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA19194 for freebsd-scsi-outgoing; Thu, 3 Oct 1996 03:23:37 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA19185 for ; Thu, 3 Oct 1996 03:23:26 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA14340; Thu, 3 Oct 1996 12:23:20 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA03073; Thu, 3 Oct 1996 12:23:14 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id MAA25420; Thu, 3 Oct 1996 12:15:52 +0200 (MET DST) From: J Wunsch Message-Id: <199610031015.MAA25420@uriah.heep.sax.de> Subject: Re: hp4020i on 2.1.5, and it burns, burns, burns, ... To: freebsd-scsi@freebsd.org Date: Thu, 3 Oct 1996 12:15:52 +0200 (MET DST) Cc: roberte@mep.ruhr-uni-bochum.de (Robert Eckardt) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199610022309.BAA05824@ghost.mep.ruhr-uni-bochum.de> from Robert Eckardt at "Oct 3, 96 01:09:30 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Robert Eckardt wrote: > This time I always ejected/reinserted the CD and never did an abort on the > dummy burn. (being really careful this time :-) Ah, that matches with other people's experience. I think i will forcibly unload the drive at least after the fixation command in a dummy burn. > 679833600 bytes transferred in 2217 secs (306645 bytes/sec) This is the expected data rate: j@uriah 157% echo 'scale=3; 350 / (2352 / 2048)' | bc 304.878 Double speed means 350 KB/s raw data, for 2352 bytes per block. Since the drive supplies the 304 error correction and pointer bytes, the data rate into the drive is ~ 300 KB/s. (20 MB machine with X11) > > But that's already the limit. Don't push it beyond it. > May be I had luck that it didn't start swapping heavily. A few > swaps are caught by the team buffer, but when it really gets into it > ... I don't have swap space on the disk i'm reading the CD data from. But i figure that this is overcautious, since once it happened that my colleague did a bunch of random seeks on another 1 GB file that was on the same disk -- he didn't realize that i was burning a CD at the same time. :-) > > I can live with mkisofs, but would like to see it supporting what > > Regarding my idea of including write support into the cd9660-FS, > I think it's very difficult (don't want to say impossible :-) since > a mounted vn-file cannot grow or shrink, but one doesn't know the final > size beforehand. A mounted vn file _can_ grow. It cannot shrink. At least, that's what i kept in mind. > > When I configured the worm support in the kernel, the CD-writer only > > shows up as the worm, no longer as cd0. When I try to mount /dev/cd0, > > it says "device not configured", which is true, it doesn't show up > > during boot. > > > > Now, worm(4) says that it should supply all capabilities of cd(4), but > > there's no worm block device (/dev/worm0). > I started wondering about this too. It's not that much a problem whether the block device is there or not, but you will notice that you can't read data through the raw device either. It is _supposed_ to work, however, so good luck in finding the actual bug! :) Including the logic for the block device is a minor piece of work then, it should be done in less than 15 minutes. > Also, are there some special commands (tools/ioctls) for reading audio-CD > tracks to disk ? (Something like creating my favorite top ten. :-) SCSI-2 did the mistake to forbid raw-reading of audio data. When CD-ROM drive vendors later realized that there's a real market for this feature (starting with the Toshiba XM3401, e.g. SGI was using this feature in their Indy's), they developed backdoor commands of their own. Thus, it will be impossible to handle all drives similar, and some of the drives won't allow it at all. I once thought about a method how to handle this, but eventually deferred all the ideas about the `cd' driver until Justin has commited his changes to the SCSI subsystem into the main branch. I've also got things about multi-track and multi-session CDs in mind. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)