Re: [NFS] Re: problems with reiserfs + nfs using 2.4.2-pre4

[Trond Myklebust]

>>>>> " " == Roman Zippel <[e-mail]> writes:

     > If I read the source correctly, namespace operation are done
     > with dir file handle + file name. I'm playing with the idea if
     > we could relax the rule, that all dentries must be connected to
     > the root. Inode to dentry lookups are really evil, e.g. the
     > current code ignores that there might be a fs that supports
     > links to dirs (besides that vfs doesn't support that very well
     > either).  What IMO knfsd needs is only a file handle <-> inode
     > operation and as long as the inode is not connected to a dcache
     > entry (i_dentry is empty) it gets a dummy dentry, which is used
     > for further lookups. As soon as a real dentry lookups that
     > inode, we can flush the dummy dentry (small change to
     > d_instantiate()).  This would make it possible to support fs,
     > that can't lookup ".." or it would avoid extra checks for fs,
     > that don't have real ".." dir entries.  All what a fs needs to
     > do is to generate a 16(?) byte cookie, which can be used to
     > find the inode back (with the default to i_ino + i_generation).
     > This is nothing for 2.4, but IMO something that could be tried
     > with 2.5.

Isn't this more or less the default already in 2.4?

If I read the code correctly, we set the dentry d_flag
DCACHE_NFSD_DISCONNECTED on such dummy dentries.  We only force a
lookup of the full path if the inode represents a directory or the
NFSEXP_NOSUBTREECHECK export flag is not set.

It doesn't seem like a major change to delay that full path lookup of
the dentry until nfsd_lookup('..') is actually called (in the case
where the 'subtree_check' flag isn't used).
However, outright banning lookups of '..' by any one filesystem isn't
an option: path lookups are used for a lot more than just
`getcwd'. Imagine for instance trying to follow a relative soft link
across such a filesystem.

Cheers,
  Trond