From owner-freebsd-hackers Tue Jul 9 16:20:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D84837B400 for ; Tue, 9 Jul 2002 16:20:18 -0700 (PDT) Received: from kali.avantgo.com (shadow.avantgo.com [64.157.226.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3737143E31 for ; Tue, 9 Jul 2002 16:20:18 -0700 (PDT) (envelope-from scott@avantgo.com) Received: from river.avantgo.com ([10.11.30.114]) by kali.avantgo.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 9 Jul 2002 16:20:17 -0700 Date: Tue, 9 Jul 2002 16:20:17 -0700 (PDT) From: Scott Hess To: Keith Pitcher Cc: David Gilbert , Subject: Re: [hackers] Multi CDR burn In-Reply-To: <20020709191404.GA97352@stone.locallink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 09 Jul 2002 23:20:17.0938 (UTC) FILETIME=[300F2F20:01C2279F] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 -- -- cd0 /-- cdrecord dev=1 -- -- cd1 file -> --- cdrecord dev=2 -- -- cd2 \-- cdrecord dev=3 -- -- cd3 \- cdrecord dev=4 -- -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message