Re: Unionmount: proxying the control port

[Sergiu Ivanov]

Hello,

On Mon, Jul 13, 2009 at 12:24:32PM +0200, olafBuddenhagen@gmx.net wrote:
> 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:
> >
> > > 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.

I dug a little bit into nfsd and discerned the following: nfsd uses a
node name as a filesystem identifier (fsys.c: init_filesystems,
enter_filesystem).  Therefore, if the merged tree exported by unionfs
is fed to nfsd, it will treat the whole tree as a single filesystem.
 
> > > (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 :-)

Ah, I see :-)

Well, I can't tell for sure right now.  The problem is that I don't
fully understand how nfsd uses the file handle.  I can only say that
it very much needs that (a) this handle be globally unique and (b)
that there exist a fast way to convert ports into handles and vice
versa.  Now, when this conversion is mainly managed by the filesystems
themselves, which already maintain a node cache, this is easy.
However, when speaking about cases like that of unionfs, when the
translator does not bear responsibility for all ports it gives off,
the most natural solution would be to make nfsd manage the conversion.

The simplest idea would be for nfsd to maintain something similar to a
node cache within itself, but I intuitively suppose that this is not
the best of ideas.

The best situation would be if the file handle could be easily
avoided, on which matter I cannot comment right away without a deeper
investigation of nfsd.  I think that avoiding file handles is worth
the effort, but then I remember your words about a second level of
directory structure to support NFS, which means that the effort might
be pointless due to the fact that a file-handle-like structure is
inherently necessary.

Regards,
scolobb