Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129421AbRBTPRK>; Tue, 20 Feb 2001 10:17:10 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129473AbRBTPQ7>; Tue, 20 Feb 2001 10:16:59 -0500
Received: from pat.uio.no ([129.240.130.16]:36569 "EHLO pat.uio.no")
	by vger.kernel.org with ESMTP id <S129421AbRBTPQt>;
	Tue, 20 Feb 2001 10:16:49 -0500
Message-ID: <14994.35407.280038.934149@charged.uio.no>
Date: Tue, 20 Feb 2001 16:16:31 +0100 (CET)
To: Roman Zippel <zippel@fh-brandenburg.de>
Cc: Neil Brown <neilb@cse.unsw.edu.au>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        dek_ml@konerding.com, linux-kernel@vger.kernel.org,
        nfs@lists.sourceforge.net, mason@suse.com
Subject: Re: [NFS] Re: problems with reiserfs + nfs using 2.4.2-pre4
In-Reply-To: <Pine.GSO.4.10.10102201455390.13098-100000@zeus.fh-brandenburg.de>
In-Reply-To: <shslmr11yfs.fsf@charged.uio.no>
	<Pine.GSO.4.10.10102201455390.13098-100000@zeus.fh-brandenburg.de>
X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Reply-To: trond.myklebust@fys.uio.no
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Mime-Version: 1.0 (generated by tm-edit 1.7)
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>>>>> " " == 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/