Re: Unionmount: proxying the control port

[olafBuddenhagen]

Hi,

On Sun, Jul 12, 2009 at 08:17:10PM +0300, Sergiu Ivanov wrote:
> On Sat, Jul 11, 2009 at 02:40:49AM +0200, olafBuddenhagen@gmx.net
> wrote:

> > 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.

I really can't tell; this would require digging into NFS.

> > > 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).

Yeah, that's what I meant.

> 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,

Will it really? This is the decisive point.

> > (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.

I mean whether this is fixable in nfsd -- see the point above :-)

-antrik-