Messages in this thread | | | Date | Sun, 6 Jun 1999 20:43:41 -0400 (EDT) | From | Alexander Viro <> | Subject | [RFC] symlink caching and network filesystems |
| |
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/
| |