On Tue, 9 Jul 2002, Keith Pitcher wrote:
> On Tue, Jul 09, 2002 at 07:07:54AM -0400, David Gilbert wrote:
> > Remember: unix is a system whereby you assemble piplelines and scripts
> > of _simple_ programs to create complex behavior. It's not necessary
> > to have a multi-cd tool when you can roll your own with your own
> > behavior.
> >
> > Dave.
>
> This is a simplistic and inadequate solution. UNIX was intended to be
> efficient, not to do eight Times the amount of work of any other system.
> This uses 8 times the memory, 8 times the processor, and 8 times the bus
> (only 4 times if two channels, but you get the idea). A properly written
> CD burning tool would use the SCSI commands to send the data only once
> to all of the devices.
In thinking about this, what I would really want (if I needed this) would
be a modification to cdrecord which could send the write information to
multiple drives, using a single buffer. In the straightforward
implementation, you would push the buffer forward after all drives were
done with a particular block. But if one was slow, that would result in 7
coasters. Instead, if a particular drive falls behind by more than, oh,
half the buffer, it should be cut off, creating a single coaster, rather
than 8.
Bah. If you're worried about the memory footprint of what Terry
suggested, you could, perhaps, cdrecord with a smaller buffer from stdin,
and use a seperate command to provide a larger buffer, and also tee up
multiple output streams. I know there are buffering commands out there,
and tee commands, but I suspect you'll need a bit of custom work to
generate a decent combo tool. [OTOH, that would be straightforward C
coding, might take you all of a day to implement. Perhaps you could also
work something up using an available tool and a capable shell.] You'd end
up with a nifty ASCII diagram:
/- cdrecord dev=0 -- <little buffer> -- cd0
/-- cdrecord dev=1 -- <little buffer> -- cd1
file -> <big buffer> --- cdrecord dev=2 -- <little buffer> -- cd2
\-- cdrecord dev=3 -- <little buffer> -- cd3
\- cdrecord dev=4 -- <little buffer> -- cd4
The main problem I can think of is whether cdrecord does anything
interesting to lock itself from trying to write multiple CDs at a time.
Later,
scott
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
