From owner-freebsd-stable@FreeBSD.ORG Fri Feb 9 19:07:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1107C16A400 for ; Fri, 9 Feb 2007 19:07:38 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from spunkymail-a7.g.dreamhost.com (sd-green-bigip-202.dreamhost.com [208.97.132.202]) by mx1.freebsd.org (Postfix) with ESMTP id EBBF113C4C4 for ; Fri, 9 Feb 2007 19:07:37 +0000 (UTC) (envelope-from sean@cyberwang.net) Received: from [10.0.0.31] (71-14-6-202.static.gwnt.ga.charter.com [71.14.6.202]) by spunkymail-a7.g.dreamhost.com (Postfix) with ESMTP id E944C5C144; Fri, 9 Feb 2007 11:07:36 -0800 (PST) Message-ID: <45CCC676.9070507@cyberwang.net> Date: Fri, 09 Feb 2007 14:07:34 -0500 From: Sean Bryant User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Antony Mawer , Sean Bryant , freebsd-stable@freebsd.org, Dominic Marks References: <45C52C3E.8040204@elgia.com> <20070205101806.b45f4118.dom@helenmarks.co.uk> <45C7EC5F.2030108@cyberwang.net> <45C81A5B.1010608@mawer.org> <20070207055131.GC1620@funkthat.com> In-Reply-To: <20070207055131.GC1620@funkthat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: dd as an imaging solution. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 19:07:38 -0000 John-Mark Gurney wrote: > Antony Mawer wrote this message on Tue, Feb 06, 2007 at 17:04 +1100: >> On 6/02/2007 1:47 PM, Sean Bryant wrote: >>> Dominic Marks wrote: >>>> Check out G4U (NetBSD based) >>> The only problem I can see here is that multiple parallel reads will >>> have serious performance impacts, thus greatly increasing the cloning of >>> the disk. >>> >>> The solution with dd, tee and netcat would just daisy chain the copy >>> across the network which would be way faster. >> Now all you need is G4U to operate in a multicast manner like Symantec >> Ghost Corporate Edition, and your transfer speed wouldn't reduce with >> each additional client (eg. 100mbps for 1 client, 50mbps each for 2 >> clients, 33.3mbps each for 3 clients, ...) > > Add FEC to the multicast, and you can constantly stream the data, and > not have to worry about dropped segments as much... > Can you explain this?