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

Trond Myklebust (trond.myklebust@fys.uio.no)
Tue, 20 Feb 2001 16:16:31 +0100 (CET)


>>>>> " " == Roman Zippel <zippel@fh-brandenburg.de> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/