9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Eric Van Hensbergen" <ericvh@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] 9p over high-latency
Date: Thu, 18 Sep 2008 08:34:28 -0500	[thread overview]
Message-ID: <a4e6962a0809180634o5e8eb4f6lb7e59116779d5f17@mail.gmail.com> (raw)
In-Reply-To: <0876d6a11c3a4fdd9b26e45e8e56abb2@quanstro.net>

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

My experience is that there are a couple of different scenarios here
-- there's dealing with synthetic file systems, dealing with regular
files, and then there is dealing with both.  Latency can effect all
three situations -- my understanding was that Op was actually
developed to deal with latency problems in dealing with the deep
hierarchies of the Octopus synthetic file systems.

There are likely a number of optimizations possible when dealing with
regular files -- but we currently don't give many/any hints in the
protocol as to what kind of optimizations are valid on a particular
fid -- and with things like batching walk/open its even more difficult
as you may cross mount points which invalidate the type of
optimization you think you can do.

Of course, if these were dealt with in a single protocol one approach
would be to return Error when attempting an invalid optimization
allowing clients to fall-back to a safer set of operations.  I do tend
to agree with Uriel that extensions, such as Op, may be better done in
a complimentary op-code space to make this sort of negotitation
possible.  Unfortunately this can add quite a bit of complexity to the
client and servers, so its not clear to me that its a definite win.

If you know you are dealing exclusively with regular files, I would
suggest starting with something like cfs(4) and play with different
potential optimizations there such as read-ahead, loose caches,
directory caches, temporal caches, etc.  Most of these techniques are
things you'd never want to look at with a synthetic file service, but
should provide a route for most of the optimizations you might want in
a wide-area-file-system -- particularly if you have exclusive access
and aren't worried about coherency.

If you are worried about coherency, you probably don't want to be
doing any of these optimizations.  There have been some conversations
about how to approach coherent caching, and I think some folks have
started working on it, but nothing is available yet.

                  -eric



  reply	other threads:[~2008-09-18 13:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-18 11:51 erik quanstrom
2008-09-18 13:34 ` Eric Van Hensbergen [this message]
     [not found] <0a44b94d5b9fa0b13dc1d9ae11472e5e@quanstro.net>
2008-09-18 13:34 ` sqweek
2008-09-18 13:49   ` Eric Van Hensbergen
2008-09-18 17:26     ` Francisco J Ballesteros
2008-09-18 20:05       ` Steve Simon
2008-09-18 20:38         ` Francisco J Ballesteros
  -- strict thread matches above, loose matches on Subject: below --
2008-09-18  9:57 sqweek
2008-09-18 10:36 ` Christian Kellermann
2008-09-18 10:48   ` Uriel
2008-09-27  1:17 ` Nathaniel W Filardo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4e6962a0809180634o5e8eb4f6lb7e59116779d5f17@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).