From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 21 Feb 2011 09:47:33 -0500 To: 9fans@9fans.net Message-ID: <2747a607ba16b358a5591ed273b94f0d@ladd.quanstro.net> In-Reply-To: <20110220234929.DA23A5B58@mail.bitblocks.com> References: <201102181445.41877.dexen.devries@gmail.com> <201102181753.30125.dexen.devries@gmail.com> <7769a67a9fbc1fae2186ff9315457e0d@ladd.quanstro.net> <20110220234929.DA23A5B58@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b29b7c56-ead6-11e9-9d60-3106f5b1d025 > Caching is definitely worth doing but you don't always have > the opportunity to do it. If you are copying a lot of files > across, it would help quite a bit if you can just pipeline > requests (or send fewer bundled requests). If you are copying > very large files, streaming would help. When copying large > amounts of data from various sources to a local file server, > caching is not very relevant. i'm not sure why the focus on copying a bunch of files. i wouldn't go to the effort to better stand-alone ftp/scp/http. the application is a file server and you choose to operate synchronously, between amdahl's law and the speed of light, you're going to be in quite a box. as a contrived example, imagine two nodes of a distributed fs 80ms apart. now imagine both nodes writing to /sys/log/timesync. naively copying and locking is going to be so slow that one imagines that timesync will drift off course. :-) - erik