From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30809180634p393897b2r2bb7eed6cc8060ee@mail.gmail.com> Date: Thu, 18 Sep 2008 21:34:43 +0800 From: sqweek To: "erik quanstrom" In-Reply-To: <0a44b94d5b9fa0b13dc1d9ae11472e5e@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0a44b94d5b9fa0b13dc1d9ae11472e5e@quanstro.net> Cc: 9fans@9fans.net Subject: Re: [9fans] 9p over high-latency Topicbox-Message-UUID: 11d97950-ead4-11e9-9d60-3106f5b1d025 On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom wrote: >> Hm, but what's the alternative here? Readahead seems somewhat >> attractive, if difficult (I worry about blocking reads and timing >> sensitive file systems). > > the fundamental problem is that it becomes very difficult to > implement fileservers which don't serve up regular files. > you might make perminant changes to something stored on > a disk with readahead. I'm not sure this problem is insurmountable. Some simple heuristics along the lines of waiting a couple of Rreads to see if it looks like an i/o pattern that is slurping up the whole file could go a long way. However, I agree this is not the most reliable approach, and certainly doesn't fit with the simplicity ideal. > i'll admit that i don't understand the point of batching walks. > i'm not sure why one would set up a case where you know you'll > have a long network and where you know you'll need to execute > a lot of walks. most applications that do most i/o in a particular > directory set . to that directory to avoid the walks. Right, but unless the mnt driver keeps an fid around for every file in that directory set, every open is still two round trips - one to walk to the file, and one to actually open it. Which is almost twice as long as necessary. You might scoff at a single round trip, but as someone who uses ircfs over the internet, I can tell you the difference in responsiveness between echo and cat is noticeable (though ok, echo has two extra round trips in this case). > i'm not sure that octopus wouldn't be better off optimizing > latency by running many more threads. but that's just an ignorant > opinion. How can multiple threads possibly help with latency caused by operations that forced to be serial by the protocol? In fact, how can multithreading help with latency in general? It will help *throughput*, certainly, but unless you have a thread dedicated to predicting the future, I can't see where the benifit will come from. -sqweek