Date: Fri, 09 Feb 2007 14:07:34 -0500 From: Sean Bryant <sean@cyberwang.net> To: Antony Mawer <fbsd-stable@mawer.org>, Sean Bryant <sean@cyberwang.net>, freebsd-stable@freebsd.org, Dominic Marks <dom@helenmarks.co.uk> Subject: Re: dd as an imaging solution. Message-ID: <45CCC676.9070507@cyberwang.net> In-Reply-To: <20070207055131.GC1620@funkthat.com> References: <45C52C3E.8040204@elgia.com> <20070205101806.b45f4118.dom@helenmarks.co.uk> <45C7EC5F.2030108@cyberwang.net> <45C81A5B.1010608@mawer.org> <20070207055131.GC1620@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45CCC676.9070507>