not for 9p, but in 1993, when Gene Kim interned with me at the
Supercomputing Research Center, we did this:
https://www.semanticscholar.org/paper/Bigfoot-NFS-%3A-A-Parallel-File-Striping-NFS-Server-(-Kim/19cb61337bab7b4de856fcbf29b55965647be091,
similar in spirit to your idea.
The core idea was that we distributed the files over the set of
servers, and replicated directory trees to avoid the usual troubles:
we did not want to implement a metadata server. So each NFS request
was fanned out to 32 machines, vector rpc style, and because the
networks of that time were so slow, it was not that much slower than
you'd expect.
It worked, it gave us what was at the time a really big NFS server,
the paper got rejected twice at usenix, the original full paper is
long lost, the code? probably lost too.
It was available from super.org in 1993, but ... that's not on the
wayback machine.
On Sat, May 28, 2022 at 11:45 AM Skip Tavakkolian
<skip.tavakkol...@gmail.com> wrote:
>
> Interesting idea!
>
> This assumes the downstream servers have identical namespace hierarchy; right?
>
> State management could be messy or impossible unless some sort of
> transaction structure is imposed on the {walk, [open/create,
> read/write]|[stat/wstat], clunk} sequences, where the server that
> replies to walk first, gets that transaction.
>
> On Sat, May 28, 2022 at 9:04 AM <fge...@gmail.com> wrote:
> >
> > Has anybody considered (or maybe even implemented) a 9p server to
> > multiply incoming 9p messages to 2 or more 9p servers?
> > Maybe with 2 different strategies for responding to the original request?
> > 1. respond as soon as at least 1 response from one of the 9p servers
> > is received,
> > 2. respond only after all responses had been received.
> > thanks!
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M7413556639c5150cb4c6e116
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
