Hi, On Wed, Jul 08, 2009 at 09:39:06PM +0200, Carl Fredrik Hammar wrote: > On Wed, Jul 08, 2009 at 03:41:51PM +0300, Sergiu Ivanov wrote: > > On Tue, Jul 07, 2009 at 09:50:12PM +0200, Carl Fredrik Hammar wrote: > > > On Tue, Jul 07, 2009 at 08:55:37PM +0300, Sergiu Ivanov wrote:
> > > > * 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. [...] > Perhaps I should clarify, I meant that it doesn't make sense to > forward the RPC completely if implemented in unionfs, since unionfs > does have run-time options that users might want to fiddle with. That > is, forwarding should only be done for the --mount option. Well, we are only talking about the transparent case (--mount) here -- the unionfs translator hides itself completely in this case, and things look just as if the mountee were sitting directly on the underlying node. In this case, we definitely want to forward these RPCs. For the non-transparent case (--no-mount), we do not proxy the control port at all; the unionfs translator handles all fsys_ RPCs itself. You are right that it *could* be useful if the --mount arguments were forwarded to the mountee when doing fsysopts -- but this is a different matter :-) -antrik-
