Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Sep 2005 11:22:24 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, kamalp@acm.org, freebsd-hackers@freebsd.org, Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru>
Subject:   Re: vn_fullpath() again
Message-ID:  <20050907111035.B85520@fledge.watson.org>
In-Reply-To: <200509070215.j872FeQE040259@apollo.backplane.com>
References:  <E1ECemU-0004dI-00.shmukler-mail-ru@f26.mail.ru>  <868xyack37.fsf@xps.des.no> <ac7deb5050906082961c84a44@mail.gmail.com> <20050906191929.E78038@fledge.watson.org> <200509070215.j872FeQE040259@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Sep 2005, Matthew Dillon wrote:

>    NFS views from the client are one of those shades of gray, since
>    files and directories can be ripped up by other clients or the
>    server, but since clients have to assume a certain level of
>    consistency anyway it's hardly a show stopper from the point of view
>    of any real-life use or need.

The NFS server problem I was referring to specifically came up in the case 
of the DTE work is as follows, and can't be solved through modifications 
to the name cache:

- An NFS client uses lookups to retrieve the file handle of /foo/bar/baz
   on an NFS server.  It sets the cwd of a process on the client to that
   handle.

- The NFS server reboots, flushing its name cache and other state.

- The NFS client begins to look up and access files relative to the handle
   of /foo/bar/baz, which is fine because it has a file handle.

All further file access by the NFS client is done relative to directories 
that don't appear in the name cache unless faulted in through further 
access to that directory via the file system root, and access to existing 
open files may be done without access to any directory at all.  It may 
even happen if the file isn't open on the client but the path data is 
cached in the client avoiding server access. This doesn't just apply to 
direct remote access -- local access by file handle for rpc.lockd and 
friends is similarly affected, such as access via fhopen() in order to 
proxy locking operations.  In the case of DTE, the file server was 
required to reconstruct a path to the directory and files, which in the 
case of a pure directory access required a number of I/O's to walk up the 
tree to the root.  In the case of simply accessing a file and not a 
directory, it required an O(1) search of directories on the disk to find a 
directory that referenced the file.  Both of these mechanisms fall 
ratherly firmly into the "undesirable" category, but are necessary if you 
want reliable and arbitrary vnode->path conversion.

Hence my asking about who the consumer is, when they need the data, and 
how timely the data needs to be. If you're only interested in the actions 
of local processes, then the name cache can be a somewhat reliable source 
of name data.  If you're also interested in identifying the actions of 
remote consumers of files accessing by file handle, which may account for 
the majority of activity on a file system on an NFS file server -- i.e., 
for a server side access monitoring tool, then that may cause significant 
difficulty.  This is because, as has been discussed extensively, paths are 
traversals of a name space at a particular time, and not properties of 
files themselves.

Robert N M Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050907111035.B85520>