Hello, On Wed, Dec 3, 2008 at 3:40 AM, <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 25, 2008 at 07:49:18PM +0200, Sergiu Ivanov wrote: > > On Thu, Nov 20, 2008 at 10:27 PM, <[EMAIL PROTECTED]> wrote: > > 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. > By proxying control ports do you mean creating shadow nodes containing ports to the real control ports? If I understand your idea correctly, than the problem that bothers me is that each step in traversing the translator stack will require additional switch to nsmux. However, I do not really see another viable solution indeed. 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... > You know, right now the nsmux does forward the retries and the user sees the mirrored tree as a real filesystem. This is the standard behaviour of netfs_S_dir_lookup and my modifications to this routine did not touch this region. For an example of retry forwarding see, for instance, http://github.com/scolobb/nsmux/tree/master/nsmux.c, line 1002. It seems to me that we should anyway leave these things like they are, especially as you don't seem to remark anomalies in special cases for this approach :-) BTW, could you give an example of an anomaly with the first approach? I fail to strain my imagination sufficiently to see any... > 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... Yes, this is the main problem about traversing both static and dynamic translator stacks. > Setting a dynamic > translator on top of another dynamic translator is not really different > from setting it on a static one. > You mean that setting a dynamic translator on a dynamic translator is similar to setting a static translator on a static translator, do I get it right? > > 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? > Yes, indeed... I've just never thought of this possibility, although it looks very nice and should work much better than the existing implementation. I'll modify the code accordingly. > 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.) > Yes, I understand this issue... It seems to me that when I was implementing shadow nodes I was too busy with shadowing itself to notice this problem. > 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. > I'm not sure it is possible to make it like that, because when I tried reopening ports to files using file_name_lookup* and dir_lookup using different flags, I only got a copy of the same port; there seemed to have been no actual reopening. > 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... > Since things start to get clearer now, I feel we could continue discussing mainly on the ML, while I'll be implementing the necessary changes. True, little have I coded recently, but now that we've already figured out several important things, I think I have sufficient base to come back to coding and moving things forwards. Regards, scolobb
