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

[Sergiu Ivanov]

Hello!

On Sun Sep 8, there was a discussion on #hurd between antrik and me
(scolobb), in which several important points were spoken out. I will
try to enumerate these points below:

* The nodes with translator stacks on them should not go away until
  there are clients using these translator stacks.

* No specific node caching should be done in nsmux, but rather the
  nodes should be created on demand and destroyed, when they are not
  used already (the destruction should happen precisely when the port
  to the topmost translator in the stack will receive a no_senders
  notification)

* In the current implementation of nsmux, the shadow nodes are
  maintained by nsmux, therefore all the translator stacks should be
  shut down *before* nsmux goes away when requested, lest the
  translators should become orphaned.

* A netfs node cannot go away when all references to it are gone, but
  there are senders using the port to the topmost translator in the
  translator stack sitting on this node. To make this possible, there
  should be a way to keep this node alive, probably in a more explicit
  fashion, than a node cache might have done it.

* Every shadow node should hold the information about the real
  filesystem node it is mirroring. This is currently done by storing a
  port to this real node in each shadow node.

* A shadow node may go away in case the real filesystem node it is
  mirroring goes away.

* In the current implementation of nsmux the filter will ask for the
  underlying port to be opened with O_NOTRANS. However, the port the
  filter will get will point to a netfs node, not to the real
  filesystem node. It means, that when the filter will try to trace
  the translator stack, it will find itself only (in the case of
  'file,,-u', for instance). It will not see the static translator
  stack on the real filesystem. (This problem is, probably, only
  specific to the current implementation of nsmux).

* A better implementation of nsmux should launch a separate process
  (the shadowing translator), which would do the shadowing. The
  translators requested by the users of nsmux should sit on the port
  provided by the shadow translator, instead of a port pointing to a
  netfs node maintained by nsmux. In this case nsmux can go away
  without killing shadow translators, thus allowing for the clients,
  still using their ports to dynamic translator stacks, to continue
  working even after nsmux has gone away.

* A shadow translator is a normal translator. The only difference is
  that is should probably not be seen as a member of the translator
  stack. However, as far as I can tell, this functionality could
  probably be achieved using a standard translator library (like
  libnetfs) and some tricks, so we can roughly say that a shadow
  translator is indeed quite a normal one.

* Starting a shadow translator might require a non-standard approach,
  i.e. a custom version of fshelp_start_translator_long might be
  needed.

* The shadow translator will be sitting on a clone of the root node of
  nsmux. nsmux will clone its root node for each new shadow translator
  process.

* The shadow translator will receive the path to the node it should
  mirror as a command line argument. The path will be relative to the
  root node of nsmux, which would be the underlying node of the shadow
  translator. Thus the shadow translator will have just sufficient
  information to open the node it should mirror.

* Attention must be paid to race conditions which might occur at the
  startup of a shadow translator. Most probably, nsmux will not open
  the requested file on its own. Instead, it will blindly launch the
  shadow translator and stay awake to pass the possible errors
  returned by the translator to the user.

* There will be no difference between shadow translators mirroring
  regular files and translators mirroring directory nodes.

* The shadow translator will proxy name lookups on the shadowed node
  to the underlying filesystem, just as it will proxy most other
  requests.

* The shadow translator will be sitting on a node provided by nsmux,
  therefore part of its functionality will be stripped off if nsmux
  goes away: mainly this will concern lookups. However, most
  translators won't do lookups after being started, so the
  disappearance of nsmux should not really affect the functioning of
  dynamic translator stacks.

Right now the following questions have occurred to me:

* Why does a shadow translator have to be invisible on the translator
  stack? I don't think a filter will ever want to ignore a shadow
  translator, since it is pretty useless. And nobody, save for a
  filter, will possibly ever require the underlying node opened in
  O_NOTRANS fashion.

* 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?

Regards,
scolobb