From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: HAIL volunteer Rick Peralta Date: Wed, 29 Jul 2009 13:59:28 -0400 Message-ID: <4A708E00.5000304@garzik.org> References: <29025029.1248785350151.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <4A6F5A3E.1070907@garzik.org> <4A704376.6000303@tiac.net> <4A705D5C.9050909@garzik.org> <20090729105202.7d0410de.zaitcev@redhat.com> <4A70842E.8020908@garzik.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4A70842E.8020908@garzik.org> Sender: hail-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Pete Zaitcev Cc: Rick Peralta , Project Hail , zaitcev@redat.com Jeff Garzik wrote: > Pete Zaitcev wrote: >> In particular I'm >> going to fight hard any talk of Chunk doing its own replication, >> for now at least. > > WRT chunkd and replication, yes, that's fine for version 1.0. > > But consider which is more likely to have bandwidth to spare: > > a) client -> service > or > b) service -> service > > Of the two, I'd say "a" is a bit more likely to be remote (WAN) and have > a slow-upload situation like my home cable modem (1 mbps down, 50 kbps > up), and "b" is more likely to be LAN. > > Or to take converse logic -- is it likely that service->service > replication is SLOWER than client->service replication? > > Every way I look at it, client->{service,service,service} replication > seems both easy... and potentially slower than alternatives :) To elaborate a bit more... there obviously are cases where you want the client to be the genesis of parallel data streams into the cloud. My point was more that there are real world situations where multiple outgoing streams from the client is significantly slower than a single stream into the cloud, plus asking the cloud to perform further copies. Jeff