Re: Unionmount: proxying the control port

[Carl Fredrik Hammar]

Hi,

On Tue, Jul 07, 2009 at 08:55:37PM +0300, Sergiu Ivanov wrote:
> It was agreed that unionmount should forward some of the RPCs invoked
> on its control port to the mountee.  Most (if not all) of such RPCs
> are the fsys_* ones.  I've made up a list of RPCs which should be
> proxied in my opinion and I've also added a short explanation as to
> how this proxying should work:
> 
> * fsys_goaway: Both the mountee and unionmount should go away.
>
> * fsys_syncfs: Sync both the mountee and the underlying filesystem.

Yeah, these two are no-brainers.  The second one should also be in
unionfs.

> * fsys_set_options: This RPC should be forwarded to the mountee
>   completely.  unionmount does not have any command line switches that
>   would make much sense being altered at run-time.
> 
> * fsys_get_options: This RPC should be forwarded to the mountee
>   completely.  The reasoning is the same as for fsys_set_options.

This makes sense if we have unionmount in settrans or a stand-alone
translator with only a single mountee, but not with the current
unionfs implementation.

So you should wait to implement these until that has been decided.

> There also are some RPCs which I am not certain about:
> 
> * fsys_getfile: I don't really understand what this one does.

This (and file_getfh) enables a client to go back and forth between file
ports and symbolic identifiers unique to the file (for this translator).
Judging from file_getfh's comment this is only used by NFS.

Implementing this correctly is probably tricky, as you'd have three
(at least) sources of files: the underlying filesystem(s), the mountee, and
the unioned directories.  Note that you can only control the file handles
returned by the unioned directories, as the other files aren't proxied.

The question is which file handle goes to which of the unioned file
systems, this probably can't be determined reliably.  Also you might
not have the authority to obtain the control port of the underlying
file system.  Without this, it can't be implemented.

You'll want to study how extfs/diskfs implements file_getfh before you
reach any final conclusion though.

Also this should be implemented in unionfs as well (if its possible).

> * fsys_forward: From what antrik told me, this RPC should be forwarded
>   to the mountee completely; however, antrik also told me that this
>   RPC could be ignored, so I think I'll try to forward this completely
>   and see if it works.

Given that the only translators that implement this operation is
magic and new-fifo, I'd say you should skip it altogether.

If I'm not mistaken all this operation does is start a translator and
then forget about it, e.g. there's no need to keep track of it once its
started.  If this is the case there's no reason not to implement this
in libnetfs itself, and the other translator libraries.

And extending the translator libraries is not your current task.  :-)

> In any case, I think that the fact that these RPCs are so rarely used
> shows that unionmount can forward them completely to the mountee
> without bothering to handle them specially.

NFS support would be nice.  :-)

Regards,
  Fredrik