9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Eric Van Hensbergen <ericvh@gmail.com>
To: Francisco Ballesteros <nemo@lsub.org>,
	Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] reliability and failing over.
Date: Fri,  9 Sep 2005 20:22:04 -0500	[thread overview]
Message-ID: <a4e6962a0509091822b6bde3d@mail.gmail.com> (raw)
In-Reply-To: <600308d6050909151067389b35@mail.gmail.com>

On 9/9/05, Francisco Ballesteros <nemo@lsub.org> wrote:
> Funny. The 9p reliability project looks to me a lot like the redirfs
> that we played with before introducing the Plan B volumes into the kernel.
>

Yes, Gorka and I talked about this when he first started down the
path.  There were some differences that seemed important at the time,
but I can't recall what they were.
 
> 
> Probably, the increase in latency you are seeing is the one I'm going to
> see in volfs. The 2x penalty in performace is what one could expect, because
> you have twice the latency. However, the in-kernel implementation has no
> penalty at all, because the kernel can rewrite the mount tables.
> 
> Maybe we should talk about this.
> Eric? Russ? What do you say? Is it worth to pay the extra
> latency just to avoid a change (serious, I admit) in the kernel?
> 

Its something important to figure out.  I'll admit we are testing the
worst case scenerio here -- but the application we started the work
for (inter-partition communication) is very low-latency, and so its
desirable to eliminate as much overhead as possible.  Still, its worth
running local area network tests, but I'm going to go for gigabit
versus 100 mbit.  Gorka and I will work on this next week while we
finish up the recover paper.

Its quite likely I'll look at integrating something like this service
into my library-OS version of the 9P client and/or v9fs.  Still not
sure if it would make sense in Plan 9 proper or not.

        -eric


      parent reply	other threads:[~2005-09-10  1:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09 20:55 [9fans] sept. town hall meeting Francisco Ballesteros
2005-09-09 21:05 ` Uriel
2005-09-09 22:10   ` [9fans] reliability and failing over Francisco Ballesteros
2005-09-09 22:24     ` Russ Cox
2005-09-09 22:50       ` Gorka guardiola
2005-09-09 23:02         ` Francisco Ballesteros
2005-09-09 23:06           ` Russ Cox
2005-09-09 23:16             ` Francisco Ballesteros
2005-09-10 13:11           ` Sape Mullender
2005-09-10 21:36             ` Francisco Ballesteros
2005-09-10  1:22     ` Eric Van Hensbergen [this message]

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=a4e6962a0509091822b6bde3d@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=9fans@cse.psu.edu \
    --cc=nemo@lsub.org \
    /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).