Hi, On Sat, Nov 01, 2008 at 10:57:37PM +0200, Sergiu Ivanov wrote:
> When nsmux is asked to do a magic lookup, it creates a new mirror node > and sets the requested translator(s) on it. Well, let's be exact: It creates an new *shadow* node, i.e. a node that is visible only as the underlying node of the dynamic translator set on it, but never appears in the global namespace. > When somebody tries to read from this mirror node, nsmux reads from > the real filesystem and passes the information to the client. Right. Note that "client" in this case is normally only the translator sitting on the shadow node. (Though in some scenarios clients of the dynamic translator might get to see the shadow node as well... But let's not complicate matters here :-) ) > nsmux does not know whether it launches a normal translator or a > filter. Indeed. > Note that the only sensible use for a filter is placing it at the > bottom of the dynamic translator stack. I don't think this is entirely true. We haven't talked much about applying dynamic translators recursively yet, and I haven't thought about it very much either, so I'm not sure about the exact implications here. However, having a recursive translator on a parent directory, and then disabling it on some subdirectory or file, is a perfectly desirable use case -- and while I don't know how this would work exactly, it might very well be that it would involve setting the filter on top of existing dynamic translators... But even in the non-recursive case, such a situation is quite probable: All kinds of scripts might want to invoke filters, without caring what is already present on the node. OTOH, the fact that dynamic translators might be part of the filtered stack, probably doesn't give us any additional insight in the issue at hand, so I guess we can ignore the possibility here :-) > When a filter is launched, it requests the underlying node with > O_NOTRANS flag. Right, that is the initial step. As a result, nsmux returns a proxy node of the untranslated underlying node. (A "normal" proxy node -- not a shadow node -- this time...) > It then invokes file_get_translator_cntl on this port. Upon receiving > this RPC, nsmux returns the control port to the bottommost translator > in the *static* translator on the real filesystem node. More precisely, a *proxy* of the control port: nsmux needs to be remain in control, so further magic lookups are possible. > Since a filter always sits at the bottom of the dynamic translator > stack, such behaviour is quite reasonable I must be missing something here: Why does it matter whether it's at the bottom of the dynamic translator stack or not?... > (otherwise the filter would receive a control port to itself, which is > useless). It can never receive a port to itself: Remember that it sits on a shadow node, which is simply not visible from the underlying node, translated or not! > Having the control port to the bottommost translator in the *static* > translator stack, the filter starts traversing the stack upwards until > it finds a translator whose name matches the supplied target name. Right. > It then returns the port to the translator located just *beneath* this > matching translator. Well, the port to a proxy of the translator to be exact :-) > Now the problem: suppose the translator that is to be filtered out is > exactly the bottommost translator in the static translator stack. > Following its standard strategy, the filter will return the port to > the translator which is exactly beneath the very first matching > translator. It will therefore return the port to its underlying node. Indeed. (Except that it is in fact again a *proxy* of the underlying node...) > However, when the client will try to read from this port, their > request will be processed in nsmux and the information will be read > from the top of the static translator stack, Sorry, why? The node that the filter got here, and then passed on to the client, was a proxy of the *untranslated* underlying node! So I must admit that I fail to see a problem here... Am I missing something? -antrik-
