Re: [9fans] reliability and failing over.

[Francisco Ballesteros <nemo@lsub.org>]

Beware of the latency.

Plan B usage shows that latency is the biggest problem.
I admit that only in unions, but if you join N different file servers
in a directory, and then you dup the latency, it may be a problem.
A workaround is just not to join too many servers, but it's a workaround,
not a fix.

Anyway, when I complete volfs we'll see if it´s beareable or not.
If it is, I'll be happy to discard the kernel changes.  If it's not,
we'll have to see why.

On 9/10/05, Gorka guardiola <paurea@gmail.com> wrote:
> On 9/9/05, Russ Cox <rsc@swtch.com> 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.
> > > It provided failover (on replicated FSs, by some other means) and could
> > > recover the fids justh by keeping track of their paths.
> 
> It is almost the same thing. The difference is that one is 9P-9P
> an the other is 9P-syscall(read-write...). We didnt have a plan 9 kernel on the
> other side, so we couldnt use redirfs, that is why we ported recover.
> It is better for linux (p9p) too, as it doesnt require to mount the
> filesystem and then use it, so you dont depend on having someone to
> serve the 9P files by mounting them. I am not sure about Plan 9. On
> one side, recover knows more about the stuff under it, so it has more
> granularity, and can fail in a nicer way. On the other side, redirfs
> is much much simpler.
> 
> > >
> > > The user level process I'm with now is quite similar to that (appart from
> > > including the language to select particular volumes) it maintains a fid
> > > table knowning which server, and which path within the server are the ones
> > > for each fid. It's what the Plan B kernel ns does, but within a server.
> > >
> > > 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?
> >
> > I keep seeing that 2x number but I still don't believe it's actually
> > reasonable to measure the hit on an empty loopback file server.
> > Do something over a 100Mbps file server connection
> > talking to fossil and see what performance hit you get then.
> 
> Yes, this increase in latency is in the loopback. If you are
> using a network it is probably completely lost in the noise, the
> network being probably 100 times slower than the loopback.
> 
> >
> > Stuff in the kernel is much harder to change and debug.
> > Unless there's a compelling reason, I'd like to see it stay
> > in user space.  And I'm not yet convinced that performance
> > is a compelling reason.
> 
> I agree, though it depends on the application. For us (normal users) I
> agree completely that it is not compelling. Some people out there are
> doing stuff in which performance
> is important (let them write the code? :-)).
> --
> - curiosity sKilled the cat
>