> So, it's easy enough to avoid,
Every user knows exactly which directories you will designate as export
points in the future? I may or may not know a link crosses an export
boundary until someone emails me a flame about it, even if I check
at the time I make it.
> but what is the design intent of knfsd
> here? I thought it intended to regard each export as a self-contained
> consistent filesystem, which is a necessary constraint if we want to use
> the unmodified inode number as a fileid. But we'll need some way of
> guarding against symlinks ...
If "self-contained" includes a sense of what is not supposed to be in
the exported filesystem, as well as what is supposed to be in there,
you can't have both self-contained and internally consistent in the
presence of symlinks leading outside the filesystem. You would expect
something like "nfs_mountpoint/.." to not refer to anything on the
server; why should symlinks be any different?
Further, client-side chasing of symlinks is a feature, albeit not a
server performance feature; without this, you can't escape from an
NFS-mounted filesystem via symlink, unlike local filesystems. I did some
client-server development, with an NFS-mounted ~, and while server_data was
a regular directory (local to the server, natch), client_data was a symlink
into /tmp. This would fail (in the best case) if the nfsd were to chase
all my symlinks on the server; further, I would not have been able to
place any client-local storage under my home directory, as the server
would foil such attempts by chasing the symlinks itself. The correct
behavior, already exhibited by the non-k nfsd, was to give me my
stuff in /tmp when I accessed client_data from the client, and to
behave as normal for a dangling symlink if I tried to use client_data
from the server.
Keith