>>>>> " " == Roman Zippel <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
