From: Brent Callaghan (brent@jurassic)
Date: 03/23/97-06:48:23 PM Z
Date: Sun, 23 Mar 1997 16:48:23 -0800 (PST) From: Brent Callaghan <brent@jurassic> Subject: Re: FH -> pathname Message-ID: <Roam.1.1.859164503.3219.brent@jurassic> Carl Beam (beame@bws.com) writes: > I am surprised at these statements. I am not a Unix system developer, > but it would seem to me to be a trivial operation. An INODE is a 4 > byte value. A File Handle is a 32 byte value. If a file handle > contained the INODE of the file plus the INODE of the directory which > contained the file (in fact since a filehandle is return from a LOOKUP > command, the INODE of the directory would be easily available for > placing in the filehandle), then getting the filename would be > trivial: > > Using the INODE of the directory, do a equivalent of an INODE LOOKUP > (this would actually take less time to execute that a normal NFS > LOOKUP) and you have the name of the file. Then do an NFS LOOKUP of > ".." given the INODE of the directory contained in the file handle. > Now you have the the INODE of the directory and the the INODE of the > parent directory and you start the process again until an NFS LOOKUP > of ".." fails. > > So the cost of this operation is somewhat less then two NFS LOOKUPs > per directory level of the file. So a ten level deep file would take > the time of twenty lookups. Doing a simple directory from a PC client > of a tiny directory causes that many lookups. > > This does not sound expensive. Is there a Unix NFS Server programmer > who could verify the validity of what I stated here? Sure, it's possible and it's not expensive in terms of the amount of work the server needs to do, however on a cost/benefit tradeoff it is expensive if the server needs to stuff the fileid for the directory into every filehandle for the extremely rare case that someone wants to do a reverse FH -> filename mapping. If we require users, or sysadmins to reverse-map filehandles to server paths, then it's time to take a step back and look at Ease-of-Use. What can we do in the protocol or its implementations to eliminate the need for backward mapping ? Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:37 AM Z CST