Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Oct 1996 12:15:52 +0200 (MET DST)
From:      J Wunsch <j@uriah.heep.sax.de>
To:        freebsd-scsi@freebsd.org
Cc:        roberte@mep.ruhr-uni-bochum.de (Robert Eckardt)
Subject:   Re: hp4020i on 2.1.5, and it burns, burns, burns, ...
Message-ID:  <199610031015.MAA25420@uriah.heep.sax.de>
In-Reply-To: <199610022309.BAA05824@ghost.mep.ruhr-uni-bochum.de> from Robert Eckardt at "Oct 3, 96 01:09:30 am"

next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610031015.MAA25420>