From: vander@flab.fujitsu.co.jp (Mike van der Velden)
Newsgroups: comp.protocols.nfs
Subject: Re: /etc/mtab and file lookup
Date: 13 Oct 92 04:27:45 GMT
	<1aicbgINN8t7@early-bird.think.com>
	<VANDER.92Oct7084445@vancouver.stars.flab.Fujitsu.co.jp>
	<1992Oct10.085819.4658@ssigv.UUCP>
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan


Well, as I see it, here is another place where a prefix table would
improve correctness.

In article <1992Oct10.085819.4658@ssigv.UUCP> gdonl@sunrise.ssi1.com (Don Lewis) writes:
> 	mount hosta:/ /hosts/hosta/rootdir
> 	mount hostb:/ /hosts/hostb/rootdir
> 	echo hosta >/hosts/hosta/rootdir/tmp/hostname
> 	echo hostb >/hosts/hostb/rootdir/tmp/hostname
> 	mv /hosts/hosta /hosts/foo
> 	mv /hosts/hostb /hosts/hosta
> 	mv /hosts/foo /hosts/hostb
> 
> What does "cat /hosts/hosta/rootdir/tmp/hostname" print if /etc/mtab
> is used as a path name prefix?
> 
> What about "cd /hosts/hostb; cat rootdir/tmp/hostname"?

Well, considering that I've already described how some mechanism for
updating the prefix is necessary, I'd see this as a trivial extension.
The above example, while possible, is extremely contrived, IMHO.  A
more likely scenario would see the access permissions to one of the
parent directories being changed.  These changes would have to be
recorded in the prefix table in order for it to work properly.  Now,
if you already have the capability of determining that one of the
directory inodes in the prefix table is being affected, it should be
relatively easy to update it for the above example.

Let me now show how the current lookup implementations give incorrect
results, IMHO, while a prefix table implmentation would give correct
ones.  Try the following commands after your example above:

[1]:  df
Filesystem    . . .        Mounted on
hosta:/                    /hosts/hosta/rootdir
hostb:/                    /hosts/hostb/rootdir

[2]: umount /hosts/hosta/rootdir
[3]: df
Filesystem    . . .        Mounted on
hostb:/                    /hosts/hostb/rootdir

[4]: cat /hosts/hostb/rootdir/tmp/hostname
hosta

Now, if a considerable period of time had elapsed between [2] and [3]
(say with different users, even), this gives totally unexpected
information.  Is it correct?  Well, IMHO, no, but then others might
have a different opinion.  In any case, the output of the df command
*is* incorrect, no matter how you look at it.

A prefix table implementation should show the following output for the
'df' command:

[3]: df
Filesystem    . . .        Mounted on
hostb:/                    /hosts/hosta/rootdir

Then, even though the following 'cat' command prints the same output
as in the current implementation, "hosta", this behavior is expected
and correct.


> 
> >... and a side
> >effect should be improved performance.
> 
> In the second case, does the lookup have to to a getwd() in order to
> figure out the full path name so it can find the correct prefix?

Well, one can search the prefix table by inode as well as by pathname,
so if your current directory's inode is in the prefix table, you've
got your 'cwd'.  But to simply prepend this to the target filename (in
this case "rootdir/tmp/hostname") would be wrong.  Relative pathnames
do pose a bit of a problem that I haven't spent too much time on.

What I want from my prefix tables is to correct problems such as
described in the first example above, or where one file server is
mounted as a subdirectory of another (see previous posts).

I gather that not much work has been done in this area, or that the
problems with the current file lookup implementations are just not
that important.  As I mentioned earlier, these problems are avoided by
workarounds and conventions, rather than application robustness;  ie.
we live with these problems.  

Does anyone have any references on similar or related work?
 
--
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
Xref: sparky comp.protocols.nfs:2527 comp.protocols.iso:1251