From: vander@flab.fujitsu.co.jp (Mike van der Velden)
Newsgroups: comp.protocols.nfs
Subject: /etc/mtab and file lookup
Summary: file lookup, prefix tables, /etc/mtab
Date: 2 Oct 92 02:59:00 GMT
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan


Perhaps this is a really braindead question, but as the saying goes,
open your mouth once, and you're a fool for 5 minutes, but keep your
mouth shut, and you're a fool forever.  Or something like that.  Anyway...

Why doesn't the file lookup operation use the information in /etc/mtab
as a prefix table?  I was reading the explanation in the Nutshell
Handbook, "Managing NFS and NIS," by Hal Stern, but it just explains
why file lookup is done on the client rather than on the server.  To
use an example similar to the book's, let's assume that /etc/mtab
contains the following information:

wahoo:/usr/local /usr/local nfs ro,hard 0 0
zippy:/usr/local/bin.mips /usr/local/bin  nfs ro,hard 0 0

(I realize that its not good practice to put one mounted directory
below another one, but let's leave that aside for now).  Suppose that
you wanted to run /usr/local/bin/emacs.  What the file lookup
operation does is search through the / directory until it finds /usr,
then search through /usr until it finds /local.  At this point, the
lookup function realizes that local is mounted from another server, so
it contacts wahoo to get the /usr/local directory information.
Searching /usr/local, it finds the bin and its file handle, and
realizes that its mounted as well.  It then contacts zippy to get the
directory information for /usr/local/bin.mips.  Finally, the lookup
function scans this directory to find the file handle for emacs, and
we're on our way.  (The DNLC does speed this process up somewhat)

Wouldn't it be faster for the lookup operation to first scan /etc/mtab
for the longest matching prefix, and then contact the appropriate
server directly?  In that case, if wahoo was down, the client wouldn't
notice, and could still run the desired program.  (This is one of the
reasons that it is not good practice to mount one directory below
another).  Similary, operations like cwd would perform better.

The only reason I can see this not currently being done is that access
permissions are not stored in /etc/mtab.  For example, if only users
from a certain group were permitted to use /usr/local (ok, so this is
not a really good example, but I hope you get what I mean), then only
users from that group would be permitted to use /usr/local/bin.  Using
/etc/mtab as a prefix table would allow this security to be bypassed.

The solution to this, of course, it to use a real kernel prefix table,
that stored not only the mounted directory and the mount point, but
also the access permissions of each directory leading up to the mount
point.  Thus, when the file lookup function finds the longest matching
prefix in the table, it checks the access permissions stored there as
well, and only if permission is granted is the remote file server
accessed.  What happens if the permissions to the upper directories
change?  Well, I think this is pretty rare in any case, but perhaps
some machanism could be introduced which would update the prefix table.

I think this would provide a performance increase, possibly reducing
network traffic, and it would allow system administrators to mount
file systems as subdirectories of other mounted file systems in a
robust fashion.  Right now, convention, rather than application
robustness, prevents problems from occurring with mounting filesystems
as subdirectories of one another.

Comments?  Flames?

 
--
Mike van der Velden
Distributed Systems Laboratory, Fujitsu Laboratories Ltd., Kawasaki, Japan
e-mail: vander@flab.fujitsu.co.jp

ps. If you send me a picture postcard      Mike van der Velden
    from your area to the address at       Fujitsu Unoki Dormitory, room 227
    right, I'll send you one from Tokyo.   2-17-18 Unoki, Ota-ku, Tokyo 146
    Postcards must be received by          Japan
    November 15, 1992