Re: A New Design of nsmux (discussed on IRC on 2008/09/07)

[olafBuddenhagen]

Hi,

On Thu, Sep 18, 2008 at 10:34:22PM +0300, Sergiu Ivanov wrote:
> On Fri, Sep 12, 2008 at 7:37 PM, <olafBuddenhagen@gmx.net> wrote:

> > A lot of these design considerations hinge on the question how to
> > handle recursion, i.e. what behaviour is desired if we have a
> > dynamic translator, and do further magic lookups.
> >
> > When doing magic lookups on a dynamic translator exporting a
> > directory tree, it's rather obvious that we want further magic
> > lookups to work: Say we use Flavio's unzip translator to look into
> > an OpenOffice document, we might want to use an XML translator on
> > the individual files in there. Insert any number of other examples.
> >
> > The trickier question is what to do about lookups a dynamic
> > translator does on the underlying filesystem. (This was actually my
> > main motivation for suggesting that shadow translators would do
> > lookups on the nsmux filesystem -- this way, it should work without
> > any special handling.)
> >
> > Logically I think we do want that as well: If we use nsmux, it
> > should work just as if we used a filesystem that introduces
> > namespace-based translator selection direcly in the standard lookup
> > mechanism, i.e. we really want *all* lookups to have magic handling.
>
> Do you mean by this that all lookups should pass through nsmux (or the
> corresponding shadow translator) and be performed on the virtual nodes
> provided by nsmux?

Yeah, I think so.

As for the shadow translator, this is exactly what makes me sceptical
about the whole concept: If it turns out that the shadow translator
needs to implement the magic lookups as well, this would mean that it's
essentially just another nsmux instance. I wonder whether it would
actually be useful to launch another nsmux instance, or better to handle
it all in the main translator...

Unless of course we find some (sane) way still to split the shadowing
from the magic lookup functionality -- though even then, I'm not sure it
would be really worth it...

> > BTW, I'm not quite sure now that it's really useful to have dynamic
> > translators continue working on shadow nodes when nsmux goes away.
> > nsmux is effectively serving as the main filesystem on which the
> > dynamic translators are invoked; and in other situations,
> > translators do not have any protection against the underlying
> > filesystem going away either... If they don't need the underlying
> > filesystem, they will be fine with being orphaned; otherwise, they
> > produce failures.
> 
> I was going to ask you several days ago how did you estimate the
> probability of the situation that nsmux was asked to go away and there
> were still sane and healthy clients wanting to use their dynamic
> translator stacks :-) My opinion is that such functionality is not
> critical, although we should probably try to implement it some time,
> it being a very interesting feature.

The question is really not whether it's critical or not: but whether it
even makes sense. Is it really a good thing to have different behaviour
in the case of nsmux going away than a "normal" underlying filesystem
going away? I tend to doubt it.

> > Considering that external shadow translators do not turn out as
> > simple as I had first hoped either, I'm not sure anymore whether it
> > is a useful idea at all. I haven't abandoned the idea alltogether
> > yet, but probably we shouldn't spend to much thought on it right
> > now...
> 
> I don't expect external shadow translators to be very sophisticated

Well, the problem is that even if the shadow translator itself turns out
simple, we know by now that we still need nsmux to provide some kind of
shadow nodes itself, for the shadow translators to sit on... Which makes
the whole idea rather questionable.

Also, I'm not at all convinced about the shadow translator being simple
-- as pointed out above, it might be necessary to implement magic
lookups as well. Perhaps this can be avoided, but probably only at the
cost of further complicating interaction with nsmux; in which case it
might turn out that nsmux needs to be just as complicated as if it
handled all the shadowing in the main process...

It might be possible though to find some smart way to factor the
functionality, so that recursion would be handled naturally by the
interaction between the translators, without need for any explicit
support in any of them. I don't think this would really mean a
simplification in the sum of code involved, but it might make things
simpler *conceptually*, which could still be a worthwhile goal...

> > There is another point that popped up during these considerations:
> > What if a client for some reason does multiple lookups on the same
> > magic filename? With the current approach, a new dynamic translator
> > is created every time. While this should pose no semantic problems,
> > if all translators are well designed (don't have any temporary state
> > not reflected in shared storage), it could be quite inefficient in
> > extreme cases.
> >
> > I wonder thus whether it wouldn't be advisable to share dynamic
> > translators resulting from equivalent lookups. But this would again
> > pose problems with badly designed translators, that behave
> > differently with a single instance shared between clients than
> > individual instances for each client...
> >
> > OTOH, I already found other situations in the past where we might
> > have a great many instances of the same translator invoked in
> > parallel or successively -- so I guess this is really an issue that
> > needs to be addressed on a more generic level sooner or later...
> 
> I've been thinking about this problem for about a month already, and
> my opinion is that we should share dynamic translators. I wonder
> whether it is nsmux's responsibility to care about badly designed
> translators. If dynamic translators would not be shared, it could
> indeed result in considerable overheads, and the worst thing is that
> these expenses would appear in the cases of well-designed translators,
> too.

Well, the point is that it would complicate nsmux -- implementing a
specific solution to a generic problem...

I tend to think that we should just ignore this issue here; and only
when it actually poses serious problems in practice (as I'm sure it will
sooner or later, either with nsmux or in some other situation), it
should be addressed by an independent project, at the framework level.

> > The delay of several minutes is actually not necessary for dynamic
> > translators, as presently they are never reused, so once the
> > original client drops the reference, we *know* the translator won't
> > be used anymore. It might be useful in this case to tell the
> > translator explicitely to go away, so it won't waste resources
> > sitting around -- but I don't think this is very important, so the
> > ability or non-ability to do so probably should not affect any other
> > design decisions...
> 
> I've put a corresponding item on my TODO list. I think this problem
> should be addressed quite soon, because having useless processes
> running makes me feel uncomfortable.

It's not uncommon in the Hurd: You may have noticed that ls /dev will
create several dozen processes, which will only go away after a couple
of minutes.

I'm not sure about Mach; but with a well-implemented kernel, idle
processes shouldn't cause any CPU overhead. The real problem is memory
use: If memory runs low, the idle translators will get swapped out --
and when the timeout passes, swapped in again only to go away...

Most likely it would be better to have a mechanism for idle translators
to go away under memory pressure, instead of being swapped out. Even if
a translator *will* be needed again at some point, I guess it wouldn't
be more expensive to start it anew, than doing all the swapping...

This is really quite the same problem as with various kinds of caches:
As long as there is plenty of memory, it's a good thing to keep things
around for possible reuse; but under memory pressure, it's usually
better to drop the caches than to do swapping... (Which is the main
point of Neal's thesis BTW.)

Note however that all this only becomes really relevant in conjuction
with the problem discussed above, of having many individual translators
started in parallel or successively...

> > All in all, as a first approximation, I think we should *never*
> > explicitely destroy dynamic translators -- anything else is just
> > optimization.
> 
> OK, I understand that, but still, shouldn't the dynamic translators go
> away when nsmux goes away? (IIRC, this is what we decided to be the
> best choice in case of an nsmux without external shadow translators)

Well, we arrived at the conclusion that most dynamic translators will
probably become useless when the underlying filesystem goes away, as
there is probably little point in using magic name lookups to start
translators not using the underlying node...

Yet, I don't see why we should explicitely kill them. I think they
should just deal with the underlying node going away, just as they would
have to deal with it when sitting on some other filesystem.

> > * Suppose nsmux is asked for 'file,,x'. It will set the shadow
> > > translator on a copy of its root node and will tell the shadow
> > > translator to mirror the file 'file'. Then it will set translator
> > > 'x' on top of the shadow translator. Do I understand everything
> > > right?
> >
> > Yes, that *was* the idea...
> >
> 
> OK :-) May I deduce from the fact that you stress the Past Tense in
> your words that this mechanism is likely to suffer modifications in
> the near future?

Not necessarily in the near future; but in view of the recursion
question, it's quite likely that it will have to change -- if we even
want a shadow translator at all anymore...

In any case, I don't consider it high priority. The only reason I
previously suggested implementing the shadow translator idea ASAP, was
that it seemed at that moment a vast simplification. But it's clear by
now that it isn't.

> I'm afraid, Thursday and Friday (and a bit of Sunday) will be the only
> days on which I will be able to regularly afford a decent period of
> time spent thinking and/or working on nsmux... (I will try to find
> extra time on other days, but it will happen on a rather accidental
> basis).

I envy you for being able to plan it like that... :-)

In my case, I tend to start thinking about such stuff at all possible
moments, often when I'm supposed to be doing something completely
different. The result being that I get nothing done, because I spend
most of my time thinking about stuff I will never be able to implement
anyways, as I get nothing done... [sigh]

-antrik-