Re: What shall the filter do to bottommost translators

[olafBuddenhagen]

Hi,

On Tue, Nov 25, 2008 at 07:49:18PM +0200, Sergiu Ivanov wrote:
> On Thu, Nov 20, 2008 at 10:27 PM, <olafBuddenhagen@gmx.net> wrote:
> > On Wed, Nov 19, 2008 at 10:33:51PM +0200, Sergiu Ivanov wrote:

> > > It seems to me that in this case the filter will have to be smart
> > > enough to look through the static translator stack at first and
> > > then through the dynamic translator stack. What do you think?
> >
> > I would say this should actually be handled transparently to the
> > filter. This might mean quite complicated handling in nsmux,
> > though...
> 
> In the current implementation it is impossible to do the handling in
> nsmux without serious changes: when the filter calls
> file_get_translator_cntl on its underlying node (which is currently
> the port to the shadow node), nsmux responds by offering the filter
> the port to the first translator in the real translator stack (as I
> have already mentioned). Therefore, nsmux has no further control of
> what the filter does.

Which is precisely why I said that nsmux needs to proxy control ports as
well...

> Do you mean that we will have to proxy *each* control port?

Well, we need to make sure that the user doesn't get a real control
port -- so we need to proxy every time we return a control port to the
user.

This will happen chiefly when the filter traverses the translator stack.
But there can be other situations where a client requests a control port
explicitely.

I'm not sure what to do for normal lookups, though. There are two
possibilities: Either, when a user does a lookup on the virtual tree
exported by nsmux, nsmux could do the lookup on the real tree it mirrors
in one go, handling any necessary retries internally, and returning only
(a proxy of) the requested final node to the user.

The other possibility would be to actually forward any retries, so the
user has to handle them, just as if accessing the real tree directly. In
the latter case we would have to return control ports when forwarding
retries AIUI, which we would have to proxy too.

The first variant is simpler and more efficient, and I think it should
work well in standard situations. (libc abstracts the retries anyways.)
I wonder though whether in some special cases it might cause
anomalies...

> BTW, another important thing has just occurred to me: it seems to me
> that we will have to implement a custom version of
> fshelp_start_translator anyways. The problem is that the filter
> normally requests its underlying node with O_NOTRANS. In this case,
> file_start_translator will orphan the existing dynamic translator
> stack on the given shadow node to make the filter be the bottommost
> translator (IIRC, I told you about this problem by the end of August).

I think I see now where the confusion comes from: Every dynamic
translator gets its *own* shadow node to sit on. When dynamic
translators are stacked, each new one gets a shadow node mirroring the
underlying translator. Each dynamic translator is only seen by its own
clients, but never by an underlying dynamic translator, just as it is
never seen by an underlying static translator... Setting a dynamic
translator on top of another dynamic translator is not really different
from setting it on a static one.

> When nsmux is asked to do a magic lookup, it creates a shadow node. It
> opens a port to the real file with the flags suggested by the client
> and stores the port in the shadow node (this should be okay since
> we've already discussed it).

I don't quite remember what we said back then, but I wonder now: Why
would you open the mirrored node already at the time the shadow node is
created? Why not simply open it only the moment the shadow node is
opened, i.e. when the dynamic translator gets its underlying node?

At that time we know what flags are really asked for. (Using the flags
from the client doing the magic lookup is just wrong -- although many
translators will open the underlying node with the same flags as the
translated node, other cases are perfectly valid too.)

If we find it desirable after all to open the mirrored node immediately
for some reason, there is yet another possible variation I think: The
shadow node could get only an unauthenticated port to the mirrored node
on creation, and do the proper open only once it gets an actual client
request.

> P.S. Sorry for the delay... I will try to make it so that my answers
> will be more prompt in the future.

No worries -- as you know, I'm often very slow with my answers myself
:-)

If there is anything we need to sort out urgently, because it blocks
further work, we probably should try to discuss it on IRC instead...

-antrik-