Re: [9fans] 9p over high-latency

[erik quanstrom <quanstro@quanstro.net>]

> On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom <quanstro@quanstro.net> 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