Re: How to provide proxy nodes

[olafBuddenhagen]

Hi,

On Mon, Aug 04, 2008 at 12:54:19PM +0300, Sergiu Ivanov wrote:

> [...] To provide a response to requests of this type, nsmux has to
> create *virtual* nodes, mirroring the nodes in the real filesystem,
> and stack translators upon these virtual nodes.
[...]
> The main problem is how to create and handle such virtual nodes. It is
> not very difficult to create several libnetfs nodes, which will
> contain ports to the same real file and will thus be all mirroring the
> same file (this is what is required). However, when starting
> translators using fshelp_start_translator and file_set_translator, I
> have to feed some *ports* to these routines.  Is it possible to create
> ports pointing to virtual libnetfs nodes? Or, maybe, there is a
> different way to implement such functionality?

As I understand it, when a lookup on a magic filename like "file,,x"
comes in, we first need to create a shadow node that mirrors the real
"file" node, forwarding most requests to it, but not attached to the
ordinary directory hierarchy: so other name lookups will never find this
node -- we use it only to start the "x" translator on it.

For this, we need to obtain a port pointing to the shadow node, and then
run the translator on the node, using this port.

The last step is to return the resulting translated node to the client.
Now I see two options for that: Either we do the lookup with the
remaining file name components on the newly started translator, and
return the resulting port to the client. Or we just return the
translator port, along with an appropriate retry notification... Not
sure which is more correct.

Regardless of that choice, there are basically two problems with
implementing this: First, we need to obtain the port to the shadow node.
AIUI, the dir_lookup() implementation of libnetfs takes a netfs node
from the translator, creates a port pointing to this node, and returns
that port to the client. We basically need to do the same for the shadow
node: Take the node, and give us a port to it.

A somewhat icky but maybe possible approach would be for us (nsmux) not
to create the shadow node directly, but rather to invoke dir_lookup()
again on ourselfs (recurse), with some special parameters, which
indicate that we want a shadow node to be created. A port to the shadow
node would be the result, and we could then set the translator on it.

The other problem is: once the translator is started, how to return the
port to the client. From what you told me, I understand that libnetfs's
implementation of dir_lookup() always wants a netfs node, and creates a
port to that -- that there is no way to directly return an arbitrary
node (perhaps along with a retry notification) to the client.

Of course it would be possible instead of returning the port directly,
to create another proxy node, that forwards to the translator; and give
that proxy node as the result to libnetfs. This wouldn't be optimal, but
AIUI, it's the same as what you presently do when looking up normal,
non-magic files through nsmux.

We really want to avoid the unnecessary proxy node in *both* cases --
and the solution for both will probably be the same. (Note that this
only applies to *files*; when looking up directories, the proxy node
*is* needed, as further lookups might follow.)

So, it looks like with some trickery, it may be possible to implement it
with what libnetfs provides us; but in the long run, for a proper
solution to both mentioned issues, we will really have to replace the
dir_lookup() implementation by a custom one doing exactly what we
need...

-antrik-