|
|
 Up |
|
|
  |
Author: sqweeksqweek Date: Sep 18, 2008 07:02
On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom quanstro.net> 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.
|
| Show full article (2.02Kb) |
|
| | 4 Comments |
|
|
Author: Eric Van HensbergenEric Van Hensbergen Date: Sep 18, 2008 07:02
On Thu, Sep 18, 2008 at 8:34 AM, sqweek gmail.com> wrote:> On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom quanstro.net> wrote:
>
> 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.
>
I'm not saying I know it would be a good idea, but you could implement
speculative-9P which issued the equivalent of the batched requests
without waiting for the responses of the prior request -- since you
are on an in-order pipe the file server would get the requests in
order and if they all succeeded, then you've reduced some latency.
Of course any failure will cause issues, potentially bad issues (a
bunch of walks followed by a create would end badly if one of the
walks failed and the create put the file someplace undesirable).
|
| Show full article (1.60Kb) |
|
| | 3 Comments |
|
|
Author: Francisco J BallesterosFrancisco J Ballesteros Date: Sep 18, 2008 10:32
> I'm not saying I know it would be a good idea, but you could implement
> speculative-9P which issued the equivalent of the batched requests
> without waiting for the responses of the prior request -- since you
> are on an in-order pipe the file server would get the requests in
> order and if they all succeeded, then you've reduced some latency.
We did this, IIRC. It helped reduce latency, but for file trees like
the one used
by omero it was not enough (at least for 150ms rtts). In the end, the
file server
is pushing changes to the viewer via a "connection" file.
Of course, for other devices it might be fine.
|
| |
| 2 Comments |
|
|
Author: Steve SimonSteve Simon Date: Sep 18, 2008 13:09
> We did this, IIRC. It helped reduce latency, but...
Are the modified kernel files still in your venti?
I would be interested in having a play in a simple disk file
sharing environment.
-Steve
|
| |
| 1 Comment |
|
|
|
|
|
Author: Francisco J BallesterosFrancisco J Ballesteros Date: Sep 18, 2008 13:41
I think I made it using a user-level program to talk to 9p
servers trying to do some caching. I'll try to find out if I still
have it in venti,
I think I just removed
the thing after finding out it was not going to work for retrieving omero trees.
On Thu, Sep 18, 2008 at 10:05 PM, Steve Simon quintile.net> wrote:>> We did this, IIRC. It helped reduce latency, but...
>
> Are the modified kernel files still in your venti?
> I would be interested in having a play in a simple disk file
> sharing environment.
>
> -Steve
>
>
|
| |
| no comments |
|
|
