> On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom <[EMAIL PROTECTED]> 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
