headers
David Leimbach | 1 Jun 2005 17:43
Picon

Inferno as a remote filesystem server/client

I'm still very much an Inferno amateur.

Is there a way to make Inferno expose it's mounts to the host os?  NFS
really sucks and having a system like inferno to set up file "grid
points" or something to that effect would be a really neat application
 of this technology.

For example if I could use Inferno to share files from a remote server
then mount it on my "client side Inferno" then expose it to my host OS
I'd have most of what I'd want from a native 9P or Styx implementation
already handled for me by Inferno, plus I'd have Inferno to mess
around with and use as well.  A double win! :)

Dave
Permalink | Reply | 15 comments |
headers
Martin C. Atkins | 2 Jun 2005 07:39

Re: Inferno as a remote filesystem server/client

On Wed, 1 Jun 2005 08:43:48 -0700 David Leimbach <leimy2k@...> wrote:
>...
> Is there a way to make Inferno expose it's mounts to the host os?  NFS
> really sucks and having a system like inferno to set up file "grid
> points" or something to that effect would be a really neat application
>  of this technology.
> 
> For example if I could use Inferno to share files from a remote server
> then mount it on my "client side Inferno" then expose it to my host OS
>...

I've been pondering this for a while, and think it would be a very
powerful mechanism, for a number of applications.
The options seem to be:

1) Wait for v9fs
2) Write a Limbo library for FUSE, and a fileserver on top of it
	(NB there are several sub-options to this)
3) Write a Limbo library for the coda filesystem driver, and a fileserver
	on top of it
4) Write a limbo fileserver for NFS

1 is easiest (except for Eric, etc, who are doing all the hard work!), and
possibly the best long-term solution.

2 and 3 could be started now, rather than waiting for v9fs. If that is
really a constraint. I would say 2 is the second-best solution, technically,
but:

3 uses a readily-available module, rather than having to wait
(Continue reading)

Permalink | Reply | 14 comments |
headers
Martin C. Atkins | 2 Jun 2005 10:49

Re: Inferno as a remote filesystem server/client

Ugh!!!

Why did my message come back as sent to a whole list of names, not just to
inferno-list@...?

The only slightly out-of-the-ordinary thing I can see is that the To
line seems to have had a trailing comma (",").

Martin

--

-- 
Martin C. Atkins			martin_ml@...
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}
Permalink | Reply | 1 comment |
headers
C H Forsyth | 2 Jun 2005 10:59
Favicon

Re: Inferno as a remote filesystem server/client

someone, possibly `a strange man who needs no introduction' overlooked something.
i corrected it several hours ago.  the source of the
particular selection of names is rather obscure.
Permalink | Reply | 0 comments |
headers
Charles Forsyth | 2 Jun 2005 11:05

Re: Inferno as a remote filesystem server/client

> Is there a way to make Inferno expose it's mounts to the host os?  NFS
> really sucks and having a system like inferno to set up file "grid
> points" or something to that effect would be a really neat application
>  of this technology.

any particular types of target system?

>2) Write a Limbo library for FUSE, and a fileserver on top of it
>	(NB there are several sub-options to this)

i've just looked at that.  it doesn't look
that difficult to me to do a Limbo version of lib/fuse.c, which
might be useful generally.  well, generally on Linux.

i see that they pass the messages as structs that are read and written
on a file descriptor between kernel and program
(ie, without putting it in a simple platform-independent form).
it's interesting that after all this time, people still ``just don't get it''.
Permalink | Reply | 1 comment |
headers
Eric Van Hensbergen | 2 Jun 2005 15:22
Picon
Gravatar

Re: Inferno as a remote filesystem server/client

On 6/2/05, Martin C. Atkins <martin_ml@...> wrote:
> On Wed, 1 Jun 2005 08:43:48 -0700 David Leimbach <leimy2k@...> wrote:
> >...
> > Is there a way to make Inferno expose it's mounts to the host os?  NFS
> > really sucks and having a system like inferno to set up file "grid
> > points" or something to that effect would be a really neat application
> >  of this technology.
> >
> > For example if I could use Inferno to share files from a remote server
> > then mount it on my "client side Inferno" then expose it to my host OS
> >...
> 
> I've been pondering this for a while, and think it would be a very
> powerful mechanism, for a number of applications.
> The options seem to be:
> 
> 1) Wait for v9fs
>

v9fs should "generally" work for this, although I haven't added an
Inferno server to my standard regression yet.  I'll re-install Inferno
from the current release and give it a shot.  Of course, it might be
nice to have a "cut" through transport (shared memory, named pipes,
something else?) instead of talking over TCP - but I suppose it should
"just work".

As Martin points out, v9fs isn't mainstream Linux (yet), but we
install fairly nicely as a kernel module as long as you are running
2.6.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Forsyth | 2 Jun 2005 15:41

Re: Inferno as a remote filesystem server/client

i've already done a bit of work on FUSE.
it's not too bad so far.
errnos, though.
``why oh why oh why?''
Permalink | Reply | 0 comments |
headers
Martin C. Atkins | 2 Jun 2005 16:52

Re: Inferno as a remote filesystem server/client

On Thu, 2 Jun 2005 10:05:13 +0100 Charles Forsyth <forsyth@...> wrote:
>...
> (ie, without putting it in a simple platform-independent form).
> it's interesting that after all this time, people still ``just don't get it''.

The Coda Kernel <-> user space communication is (more or less) OS
independent. It's a pity they didn't think of it as a general-purpose
mechanism!

Martin

--

-- 
Martin C. Atkins			martin_ml@...
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}
Permalink | Reply | 0 comments |
headers
David Leimbach | 3 Jun 2005 05:12
Picon

Re: Inferno as a remote filesystem server/client

> 
> I've been pondering this for a while, and think it would be a very
> powerful mechanism, for a number of applications.
> The options seem to be:
> 
> 1) Wait for v9fs

I don't just want to connect linux boxes.  I'd love to have v9fs for
Darwin... and I'm interested in doing some of the lifting if
necessary, especially private namespaces.

> 2) Write a Limbo library for FUSE, and a fileserver on top of it
>         (NB there are several sub-options to this)

It'd have to talk Styx I suppose.

> 3) Write a Limbo library for the coda filesystem driver, and a fileserver
>         on top of it

I have 0 interest in coda. 

> 4) Write a limbo fileserver for NFS
> 

NFS doesn't scale well for what I like to do and not all NFSes are
created equal it seems.

Styx for Unix or 9P2000.u would be better long term solutions :). 
[v9fs ports being at the top of the list of good long term solutions
I'd think]
(Continue reading)

Permalink | Reply | 7 comments |
headers
Martin C. Atkins | 3 Jun 2005 06:49

Re: Inferno as a remote filesystem server/client

On Thu, 2 Jun 2005 20:12:40 -0700 David Leimbach <leimy2k@...> wrote:
>..
> I don't just want to connect linux boxes.  I'd love to have v9fs for
> Darwin... and I'm interested in doing some of the lifting if
> necessary, especially private namespaces.

Agreed. The more platforms we can get v9fs on to, the better - after all,
it is meant to be a machine-to-machine file sharing protocol too!

> > 2) Write a Limbo library for FUSE, and a fileserver on top of it
> >         (NB there are several sub-options to this)
> 
> It'd have to talk Styx I suppose.

Are you saying that the fileserver I referred to would have to talk styx?
I was assuming that it would talk open/close/read/write, ie, serve the files
that were in it's own namespace, rather than being a protocol converter (although
that approach might have other dis/advantages worth considering).

> > 3) Write a Limbo library for the coda filesystem driver, and a fileserver
> >         on top of it
> 
> I have 0 interest in coda. 

My only interest in Coda is that their kernel module (reliably)
solves (most of) this problem, and is widely available. I've been
using it in this role for nearly two years now, very successfully.
I've just this moment discovered that there is a project getting Coda
working on Darwin too,
see
(Continue reading)

Permalink | Reply | 6 comments |

Gmane