[9fans] 9p & read-ahead

[9fans] 9p & read-ahead

[steve.simon]

Hi,

I am thinking of adding read-ahead to a 9p server.
Is this a sensible thing to do? Am I being foolish
and indulging in bloatware or is it a sensible
optimisation?

My server is my Netware client. Directory scans of big
directrories is slow as is copying files. Looking at
iostats it looks like read is at fault. Netware
allows me to read big chunks of files and to scan for
multiple directory entries, So this is fairly easy,

I was planning to add a timeout on the buffer of
a seccond or two, so I don't get stale info.

Anyone any strong views about this?

-Steve

Re: [9fans] 9p & read-ahead

[boyd, rounin]

> I am thinking of adding read-ahead to a 9p server.

why not, as long as it's simple.

trying to be too smart is a lost cause when it comes to caches etc ...

Re: [9fans] 9p & read-ahead

[Bruce Ellis]

read-ahead is straightforward and has been done a few times under
different moons.  the server decides the policy and if gets it wrong
then you know who to blame.  write-ahead is more interesting and
has been done a few times (by pb and me at least) -  write-ahead
being an immediate Rwrite when you are the policy man.  (write errors
poison the chan so the next T* gets an Rerror.)  great for annoying
people by streaming video in the unix room.

brucee
----- Original Message -----
From: <steve.simon@snellwilcox.com>
To: <9fans@cse.psu.edu>
Sent: Thursday, July 31, 2003 6:29 PM
Subject: [9fans] 9p & read-ahead


> Hi,
>
> I am thinking of adding read-ahead to a 9p server.
> Is this a sensible thing to do? Am I being foolish
> and indulging in bloatware or is it a sensible
> optimisation?
 etc

Re: [9fans] 9p & read-ahead

[boyd, rounin]

> read-ahead is straightforward ...

the MD driver ...

[9fans] Re: 9p & read-ahead

[Jim Choate]

On Thu, 31 Jul 2003 steve.simon@snellwilcox.com wrote:

> Anyone any strong views about this?

Add a switch so that anyone who does in a negative way can turn it off.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

Re: [9fans] Re: 9p & read-ahead

[splite]

On Thu, Jul 31, 2003 at 06:27:24AM -0500, Jim Choate wrote:
>
> On Thu, 31 Jul 2003 steve.simon@snellwilcox.com wrote:
>
> > Anyone any strong views about this?
>
> Add a switch so that anyone who does in a negative way can turn it off.

And a light to indicate that it's on.

And a rheostat to control how much it reads ahead.

Re: [9fans] Re: 9p & read-ahead

[Jack Johnson]

splite@purdue.edu wrote:
> And a light to indicate that it's on.
>
> And a rheostat to control how much it reads ahead.

Thanks.  Now I'm envisioning big, black Nakamichi routers with giant
volume knobs for traffic shaping.

...and Monster Cable Cat5.

-Jack

Re: [9fans] 9p & read-ahead

[rog]

> great for annoying people by streaming video in the unix room.

related to this, i wonder whether anyone is using the following
technique to get around RPC latency overheads when streaming data over
9p:

allow multiple readers on the stream, but honour the read offsets:
queue "future reads", and reply to them only when all the data up to
there has been read.

to use this, a client schedules multiple reads concurrently (making
sure that each reads at a consistent offset).

the nice thing about this is that it's invisible to a naive reader,
and works just the same on static files too; it also works for writing.

ideally a client that uses this could dynamically adapt the number of
reader processes according to the data transfer rate, but i'm not
quite sure of the best way to go about this.

Re: [9fans] 9p & read-ahead

[Geoff Collyer]

Ken's file server does read-ahead and write-behind, so there's good
solid precedent.