From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <10af1064d3ac35a8d2f62214d5eec485@gmx.de> <78900b59ef46884a6fdc7924188d9760@ladd.quanstro.net> Date: Fri, 15 Oct 2010 18:05:25 -0400 Message-ID: From: John Floren To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] =?utf-8?b?z4Bw?= Topicbox-Message-UUID: 67852140-ead6-11e9-9d60-3106f5b1d025 It is probably worth trying. However, it wouldn't make copying a file from sources any faster, or help a Blue Gene node do a snapshot any quicker. John 2010/10/15 Julius Schmidt : > Perhaps I'm getting this all wrong, but to me this seems like an > interesting idea, especially if you consider the impact of being "near > the files" on some classically considered computationally stressy tasks > like compiling (esp. with kencc). So moving the code near the data > definitely seems worth trying. > > aiju > > > On Fri, 15 Oct 2010, Latchesar Ionkov wrote: > >> There are definitely cases when moving the code instead of the data >> makes sense. But that discussion is mostly unrelated to the one on how >> to make the file I/O work better over high-latency links. >> >> 2010/10/15 erik quanstrom : >>> >>> On Fri Oct 15 12:33:19 EDT 2010, lucho@ionkov.net wrote: >>>> >>>> What if the data your process needs is located on more than one >>>> server? Play ping-pong? >>> >>> one either plays ping pong with the process or data. =C2=A0one >>> could imagine cases where the former case makes sense. >>> >>> - erik >>> >>> >> >