Forward fuse requests over the network to another host (which replies).

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Forward fuse requests over the network to another host (which replies).

Stef Bon-2
Hi,

I've been thinking about the way a network fs using fuse works.

Right now as far as I can see it works like (with nfs for example):

1. fuse fs receives a request from the VFS containing an unique id, an
opcode and additional data about the request, like the name for
example when dealing with a lookup.

2. the request is translated into something with a path and the right
call using the api

(using the libnfs library for example this is nfs_stat. See:
https://github.com/sahlberg/libnfs/blob/master/include/nfsc/libnfs.h

for smb this is simular)

This call will contact the remote server and receive a reply.

3.  This reply is translated by the fuse fs into something the
VFS/FUSE module understands, as well as an entry and inode used by the
fuse fs are created when the lookup has been succesfull.

Does anyone have some experience with skipping step 2? Let me explain:

1. the first step is the same. A request is received from the VFS.

2. instead of translating it to something the client api (like the
libnfs library mentioned above) understands forward it to the remote
server, where there must be a fuse server listning on a netwoprk
socket.

3. this fuse server gives a reply, which is send back.

Does anyone have experience with this kind of use of fuse?

Stef Bon

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Forward fuse requests over the network to another host (which replies).

Antonio SJ Musumeci
What is that you're looking to do? Create a fuse network proxy? That'd be
pretty straight forward by replacing / augmenting fusermount. The protocol
may be a bit chatty though use over the network.

On Mon, Sep 28, 2015 at 9:47 AM, Stef Bon <[hidden email]> wrote:

> Hi,
>
> I've been thinking about the way a network fs using fuse works.
>
> Right now as far as I can see it works like (with nfs for example):
>
> 1. fuse fs receives a request from the VFS containing an unique id, an
> opcode and additional data about the request, like the name for
> example when dealing with a lookup.
>
> 2. the request is translated into something with a path and the right
> call using the api
>
> (using the libnfs library for example this is nfs_stat. See:
> https://github.com/sahlberg/libnfs/blob/master/include/nfsc/libnfs.h
>
> for smb this is simular)
>
> This call will contact the remote server and receive a reply.
>
> 3.  This reply is translated by the fuse fs into something the
> VFS/FUSE module understands, as well as an entry and inode used by the
> fuse fs are created when the lookup has been succesfull.
>
> Does anyone have some experience with skipping step 2? Let me explain:
>
> 1. the first step is the same. A request is received from the VFS.
>
> 2. instead of translating it to something the client api (like the
> libnfs library mentioned above) understands forward it to the remote
> server, where there must be a fuse server listning on a netwoprk
> socket.
>
> 3. this fuse server gives a reply, which is send back.
>
> Does anyone have experience with this kind of use of fuse?
>
> Stef Bon
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Forward fuse requests over the network to another host (which replies).

Stef Bon-2
2015-09-28 16:38 GMT+02:00 Antonio SJ Musumeci <[hidden email]>:
> What is that you're looking to do? Create a fuse network proxy? That'd be
> pretty straight forward by replacing / augmenting fusermount. The protocol
> may be a bit chatty though use over the network.

I'm afraid I do not understand you. fusermount is a commandline utility.

What I mean is forwarding the fuse requests coming from the VFS to
userspace to another host, connected
through a network socket.

It's not so hard I guess to program. There has to be a fuse server on
the remote host, handling the request.
What this fuse server does futher - handle the request self or contact
another service on the same host - I don't know yet.

I wonder does someone any experience with this use of fuse.

Stef

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Forward fuse requests over the network to another host (which replies).

Antonio SJ Musumeci
fusermount is what opens /dev/fuse and hand the FD to the fuse app. You
could probably augment it to transparently (to the existing fuse apps)
proxy the messages between hosts.

I've not come across anyone who's tried this. In cases where individuals
want to access something remotely they tend to use samba, nfs, or 9P to
export it over the wire.

It could be interesting to try but introduces a whole new set of issues to
account for. Not sure it'd be worth it.

On Mon, Sep 28, 2015 at 1:59 PM, Stef Bon <[hidden email]> wrote:

> 2015-09-28 16:38 GMT+02:00 Antonio SJ Musumeci <[hidden email]>:
> > What is that you're looking to do? Create a fuse network proxy? That'd be
> > pretty straight forward by replacing / augmenting fusermount. The
> protocol
> > may be a bit chatty though use over the network.
>
> I'm afraid I do not understand you. fusermount is a commandline utility.
>
> What I mean is forwarding the fuse requests coming from the VFS to
> userspace to another host, connected
> through a network socket.
>
> It's not so hard I guess to program. There has to be a fuse server on
> the remote host, handling the request.
> What this fuse server does futher - handle the request self or contact
> another service on the same host - I don't know yet.
>
> I wonder does someone any experience with this use of fuse.
>
> Stef
>
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Forward fuse requests over the network to another host (which replies).

Stef Bon-2
No I do not want to use fusermount. I "m writing my own fuse fs's
using the lowlevel api, or even without that using my own fuse
interface, not even using the fuse library.
I know what fusermount is for, I just did not understand why you
mentioned it here.

Stef

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Forward fuse requests over the network to another host (which replies).

David Sheets
In reply to this post by Stef Bon-2
On Mon, Sep 28, 2015 at 2:47 PM, Stef Bon <[hidden email]> wrote:

> Hi,
>
> I've been thinking about the way a network fs using fuse works.
>
> Right now as far as I can see it works like (with nfs for example):
>
> 1. fuse fs receives a request from the VFS containing an unique id, an
> opcode and additional data about the request, like the name for
> example when dealing with a lookup.
>
> 2. the request is translated into something with a path and the right
> call using the api
>
> (using the libnfs library for example this is nfs_stat. See:
> https://github.com/sahlberg/libnfs/blob/master/include/nfsc/libnfs.h
>
> for smb this is simular)
>
> This call will contact the remote server and receive a reply.
>
> 3.  This reply is translated by the fuse fs into something the
> VFS/FUSE module understands, as well as an entry and inode used by the
> fuse fs are created when the lookup has been succesfull.
>
> Does anyone have some experience with skipping step 2? Let me explain:
>
> 1. the first step is the same. A request is received from the VFS.
>
> 2. instead of translating it to something the client api (like the
> libnfs library mentioned above) understands forward it to the remote
> server, where there must be a fuse server listning on a netwoprk
> socket.
>
> 3. this fuse server gives a reply, which is send back.
>
> Does anyone have experience with this kind of use of fuse?

I've played with this in the context of my (partially complete) FUSE
protocol implementation in OCaml, profuse
<https://github.com/dsheets/profuse>. The important part is
abstraction and communication of C macros like errnos if you'd like to
operate over heterogeneous hosts. One of the design goals of the work
was to run a file system in a VM, potentially shared between guest
OSes.

I'd be happy to answer further questions about this but my time is
rather short and the project is on hold at the moment.

David

> Stef Bon
>
> ------------------------------------------------------------------------------
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel