Hello,
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:
> > 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.
We spoke with antrik about this yesterday; I'll make a patch a soon.
> > * 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.
> > 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?
> 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...
> 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'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.
> 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?
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.
> > * 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.
This is a good word of advice ;-)
> 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. :-)
I also checked the implementation of fsys_forward in libdiskfs and
found that it returns EOPNOTSUPP. Since libdiskfs usually has all
necessary stuff implemented properly (as different from libnetfs and
libtrivfs), I'd say we can forget about this RPC as well.
> > 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.
Regards,
scolobb
