vn_fullpath() again
Robert Watson
rwatson at FreeBSD.org
Wed Sep 7 03:22:29 PDT 2005
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
More information about the freebsd-hackers
mailing list