Re: Unionmount: proxying the control port

[Sergiu Ivanov]

Hello,

On Sat, Jul 11, 2009 at 02:40:49AM +0200, olafBuddenhagen@gmx.net wrote:
> On Fri, Jul 10, 2009 at 12:18:58AM +0300, Sergiu Ivanov wrote:
> > 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:
> 
> > Also note that no other program but nfsd in the Hurd source tree uses
> > fsys_getfile and file_getfh (and, consequently, file handles).  Also,
> > the content of a file handle seems pretty artificial, so Fredrik posed
> > the question whether the concept of a file handle makes much sense at
> > all and whether nfsd could be implemented without it.
> 
> Well, I don't know exactly why, but I do know that NFS needs some stable
> representation of nodes. I remember how in a talk about some Linux
> filesystem they said they implemented a two-level structure for the
> directory index, with the explicit purpose of getting a stable directory
> order for NFS...

Hm...  Interesting...  I have to keep that in mind :-) I wonder,
though, whether the file handle used in Hurd nsfd and libdiskfs
qualifies as a stable node representation, since it is chiefly an
index into the node cache.
 
> > Secondly, nfsd seems to concoct a globally unique thing by maintaining
> > such a structure: {filesystem index; file handle} (consider
> > hurd/nfsd/cache.c, functions fh_hash and lookup_cache_handle).
> [...]
> > Unfourtunately, unionfs (as well as a number of other translator,
> > BTW), gives off ports to the underlying filesystems, too, so this RPC
> > cannot be properly implemented.
> 
> Is this really a problem? The question is whether nfsd can deal with the
> fact that with unionfs, individual files can be supplied by different
> file systems, even in a single directory...

I'm inclined to think that nfsd won't be able to properly deal with
this situation.  Consider the situation when unionfs merges two
directories located in two different filesystems (like two
partitions).  Two different nodes, belonging to different filesystems,
may have the same node cache index.  OTOH, the directory exported by
unionfs will be qualified as a *single* filesystem by nfsd, so the
``filesystem index'' component of the handle used in nfsd will be the
same for all files in unionfs's filesystem, and the node cache index
component will be the same because two nodes *physically* belong to
the *different* filesystems.  (I hope I'm making myself clear.) In
this way, the handle used by unionfs will cease to be unique.

Basing on this considerations, I'd say that the probability of nfsd
working normally with unionfs depends on the probability of node cache
indices coinciding.  And I think that it is rather unacceptable to
have a probabilistically working nfsd :-)

> (And if it can't in the current implementation, whether this is fixable.)

I guess it's not fixable, because unionfs has no control over regular
files, and thus over the situation when node cache indices coincide.

Regards,
scolobb