From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0876d6a11c3a4fdd9b26e45e8e56abb2@quanstro.net> From: erik quanstrom Date: Thu, 18 Sep 2008 07:51:44 -0400 To: sqweek@gmail.com, 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9p over high-latency Topicbox-Message-UUID: 11d11972-ead4-11e9-9d60-3106f5b1d025 > On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote: > > as an aside: i don't think 9p itself limits plan 9 performance > > over high-latency links. the limitations have more to do with > > the number of outstanding messages, which is 1 in the mnt > > driver. > > Hm, but what's the alternative here? Readahead seems somewhat > attractive, if difficult (I worry about blocking reads and timing > sensitive file systems). But there's one problem I can't resolve - how > do you know what offset to Tread without consulting the previous > Rread's count? > Actually, I understand there has been discussion about grouping tags > to allow for things like Twalk/Topen batching without waiting for > Rwalk (which sounds like a great idea), maybe that would work here > also... 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. since one of the main points of plan 9 is to get rid of special files, ioctl's and whatnot, read ahead seems unattactive. 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. 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. - erik