From owner-freebsd-hackers Mon Jul 29 11:46: 0 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 2CCBE37B41B for ; Mon, 29 Jul 2002 11:45:52 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFE1A43E4A for ; Mon, 29 Jul 2002 11:45:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6TIjlCV055738; Mon, 29 Jul 2002 11:45:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6TIjXAo055731; Mon, 29 Jul 2002 11:45:33 -0700 (PDT) (envelope-from dillon) Date: Mon, 29 Jul 2002 11:45:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200207291845.g6TIjXAo055731@apollo.backplane.com> To: David Miller Cc: David Gilbert , Keith Pitcher , freebsd-hackers@FreeBSD.ORG Subject: Re: [hackers] Multi CDR burn References: 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, Matthew Dillon wrote: :> :> There is no multi-target command that I know of. You are absolutely :> correct in your bandwidth calculations... a SCSI bus should have no :> problem at all duping the data 8 times to each of 8 CDR's, and the :> operating system ought to do a fine job caching the input image file :> (so the data is only read off the hard disk once). CDRs are really slow :> compared to what a SCSI bus is designed to handle. :> :> I'm somewhat interested in knowing that this concept actually works :-) : :The concept works fine, but the numbers are a little off. The actual :bandwidth calculations are right, but make the assumption that the max :data transfer rate is in effect, without the overhead of :connect/disconnect/command queuing. : :Several years ago I built a DVD-ram duplicatior with FreeBSD. DVD-ram :drives, at the time, only came in 10 MB scsi versions, and they took data :at about 650Kbit. A single 10 MB scsi channel could not, however, stream :data to more than about 5 of them at once. : :As for the general concept, I can say it works fine. I built a system :with nearly 30 DVD-ram drives on 6 separate scsi channels. At first I :tried using a utility that would read from the input image (on hard :disk) and write it out to all the drives. Bad media gave me fits, Ken :Merry was a huge help with the drivers, and in the end it worked fine to :just dd the image to all of them. The CPU was an 800 MHz athlon, :admittedly much faster than a P-100, but was practically idle when copying :to all drives at once. : :--- David That's very interesting! Effectively you have a 'buffer' which is nearly all of physical memory as the kernel caches the file data you are reading (so only the first dd to request a particular sector actually has to read it from disk). As long as the various DVDs being written too do not drift apart more then the size of the cache the data would only have to be read from the hard disk once. So then it just comes down to PCI and SCSI bus bandwidth / command overhead in regards to getting the data out to the units. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message