Re: Unionmount: proxying the control port

[olafBuddenhagen]

Hi,

(Most of this is only for the record, as we already discussed it on
IRC.)

On Fri, Jul 10, 2009 at 08:52:44PM +0300, Sergiu Ivanov wrote:

> * fsys_goaway: both the unionfs (unionmount) and the mountee should go
> away.

Actually, it should be forwarded completely in the transparent case.

unionfs should automatically go away when the mountee does -- but this
is a separate issue :-)

> * fsys_set_options: in transparent mode this RPC should be completely
> forwarded to the mountee; in non-transparent mode this RPC should be
> handled in unionfs first and the (possibly) new value for the
> ``--mount'' option should be delegated to the mountee;

I'm not actually sure whether it's useful to handle it like that in the
non-transparent case...

And I would consider it an additional feature anyways, not really
crucial.

> * fsys_getpriv: * fsys_init: fsys.defs says that these RPCs should
> only be implemented by bootstrap filesystems; since unionfs will
> hardly ever be a bootstrap filesystem, these RPCs will not be
> implemented;

I'm actually not so sure about that... It *might* be useful to
union-mount the bootstrap filesystem -- I'm just not sure whether it's
even possible in theory :-)

Indeed I guess we can ignore it for now.

> * fsys_forward: in the previous discussion there is a short
> explanation why this RPC should be left implemented in the default
> version (returning EOPNOTSUPP);

Well, if it can be easily forwarded, we should -- it *might* be
useful...

> * fsys_get_options: in transparent mode this RPC should be completely
> forwarded to the mountee; in non-transparent mode the result should be
> constructed by obtaining the options of the mountee and listing them
> as the value of option ``--mountee'', together with other unionfs
> options.

Yeah, this is the exact complement of fsys_set_options().

-antrik-