Re: Unionmount: proxying the control port

[Carl Fredrik Hammar]

Hi,

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.
> > 
> > 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.
> 
> Well, the fact that currently unionmount functionality is implemented
> as additional option of unionfs should not influence the set of
> use-cases.  I mean that if unionmount is mainly about merging the
> underlying filesystem and the filesystem of the mountee, we don't
> really need to modify run-time options of unionmount, regardless of
> the way it works at the moment.

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.

> > > 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.
> 
> Yeah, I came to a similar conclusion when I looked at file_getfh and
> fsys.h, but what really embarrasses me is that the file handle from
> which fsys_getfile extracts the port right is data_t; this tells me
> nothing about what this file handle is.  You call this ``symbolic
> identifier'', could you please give some details?

I don't know the details.  :-(

Actually you should study how nfsd makes use of the handle.  In particular
find out if it assumes that the handle is globally unique, if it does
then you can to.  Then you could pass it to all file systems and use
the first one that accepts the handle.

Thinking about it, nfsd would have a hard time with files from different
translators if the file handle isn't globally unique.  How it handles
this is probably key to how to solve this issue.

> > 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.
> 
> This is true.  Since I don't really have control over anything but the
> unioned filesystem, I guess I should stick with it and drop the other
> two sources, what do you say?  OTOH, unionfs proxies directory nodes
> only and I wonder whether it makes sense to bother at all...

Doing it only for directories makes no sense at all.

> > 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.
> 
> Hm...  If one doesn't have the authority to obtain the control port of
> the underlying filesystem, how does have the right to set unionmount
> on that filesystem at all?  Or do I understand something wrong?

You can normally set a translator on files you own, no need to have
a control port to the underlying file system (just to the translator
you're setting).

> > You'll want to study how extfs/diskfs implements file_getfh before you
> > reach any final conclusion though.
> 
> I'd suppose you mean fsys_getfile ;-) Yeah, libdiskfs is a nice source
> of inspiration.

I meant file_getfh, so that you could perhaps gain info on how handles
are typically formed.  But studying how nfsd actually uses the handles
is more authoritative since that's the main use-case.

> > Also this should be implemented in unionfs as well (if its possible).
> 
> Looking at diskfs_S_fsys_getfile, I'm afraid that things are not so
> simple.  The idea is that both {diskfs,netfs}_S_fsys_getfile get a
> parameter char * handle.  diskfs_S_fsys_getfile converts this to a
> const union diskfs_fhandle* .  However libnetfs does not define
> anything more or less similar to this (I grepped for ``handle''), so I
> don't know how to treat that parameter.  Perhaps, I could use the same
> fhandle union as in libdiskfs, what do you think?

That is probably fine.

> Also, I cannot find a single libnetfs-based translator in the Hurd
> source tree that would implement the netfs_S_fsys_getfile in a
> different way than returning EOPNOTSUPP.

Depending on the details of file handles, there might be a place for
a generic implementation in libnetfs eventually.

> [...] 

> > > 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.  :-)
>  
> I'm not sure whether implementing fsys_getfile within the current
> version of unionfs will add NFS support.  diskfs_S_fsys_getfile
> ultimately operates on libdiskfs nodes.  If I simply mimic this
> behaviour, unionfs will allow fsys_getfile only on directory nodes,
> and I have already mentioned above that I'm not sure whether this is a
> meaningful thing.

Yes, you have to forward the call to the unioned filesystems for it
to be useful.

Regards,
  Fredrik