From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 7 10:22:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E05AA16A41F for ; Wed, 7 Sep 2005 10:22:28 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AE1F43D45 for ; Wed, 7 Sep 2005 10:22:28 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 44BF146B39; Wed, 7 Sep 2005 06:22:27 -0400 (EDT) Date: Wed, 7 Sep 2005 11:22:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Matthew Dillon In-Reply-To: <200509070215.j872FeQE040259@apollo.backplane.com> Message-ID: <20050907111035.B85520@fledge.watson.org> References: <868xyack37.fsf@xps.des.no> <20050906191929.E78038@fledge.watson.org> <200509070215.j872FeQE040259@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , kamalp@acm.org, freebsd-hackers@freebsd.org, Sergey Uvarov Subject: Re: vn_fullpath() again X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 10:22:29 -0000 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