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>