Beware of the latency.
Plan B usage shows that latency is the biggest problem.
That's funny. We've been working on a low-latency wireless comms protocol
here at the Labs that we've called Plan B (our wireless emulator runs on Plan 9,
of course), because we'd come to the conclusion that
Funny, I admit.
We saw the problem when combining multiple user-level file servers
(not fossil, but device drivers for X10, guis, and the like) within
the same dir,
specially on wireless at home.
Issuing requests in parallel as Russ suggested will help, for sure,
but if things
dont get too bad,
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
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
On 9/9/05, Russ Cox [EMAIL PROTECTED] 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 just by
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
On 9/9/05, Francisco Ballesteros [EMAIL PROTECTED] 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
