| Re: [9fans] 9p over high-latency |
|
 |
|
 |
|
 |
|
 |
Group: comp.os.plan9 · Group Profile
Author: erik quanstromerik quanstrom Date: Sep 18, 2008 05:02
> On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom 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
| 
