[RFC] symlink caching and network filesystems

Alexander Viro (viro@math.psu.edu)
Sun, 6 Jun 1999 20:43:41 -0400 (EDT)

Hi.
I'm finishing the local testing of patch that allows filesystem to cache
symlinks. I.e. it provides an alternative to ->readlink()/->follow_link()
pair: inode can provide ->k_readlink() method that just sets ->i_link to
the memory containing the symlink contents. Such inodes should release the
memory/buffer_head/whatever in ->clear_inode() and for them
lookup_dentry() is not recursive (well, it still is, but it can be
trivially made iterative). It's fine for local filesystems - symlink can't
change, it can be only removed and recreated. All local filesystems are
served that way just fine.

There are two special cases where this startegy is not good:
1) some procfs symlinks (they are *really* special and for them
follow_link() doesn't involve lookup_dentry() anyway). No problems - we
can simply keep the old mechanism for them.

2) NFS and friends. Can we cache the results of readlink() for them?
(provided that inode is still valid, of course). In principle we can do it
- symlinks are supposed to stay constant until they die. If the server is
running UNIX it should be OK, but what about NFS servers on VMS, NT and
other unpleasant animals? CODA probably is OK too (in the same degree as
NFS), but what about NCPFS?

Notice that I'm not talking about caching results of follow_link() - just
the (textual) contents of symlink.

Comments are more than welcome - I'ld like to convert NFS et. al. to the
new mechanism and remove the recursion in lookup_dentry() (kernel stack is
a scarce resource).
Cheers,
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/