Re: [9fans] reliability and failing over.

[Russ Cox <rsc@swtch.com>]

> 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 just by keeping track of their paths.
> 
> 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.

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.

Russ