Disabling Symbolic Link Content Caching in NFS Client

[Vivek Goyal (vivek.goyal@wipro.com)]

Hi,

We are planning to implement a set of Kernel Tunable Parameters and one
of these parameters is nfs_symlink_caching for disabling/enabling
symbolic link content caching in NFS client. Unices like Solaris have
this feature implemented.

Existing NFS client implementation in Linux performs symbolic link
content caching by default. There is no provision for disabling this
caching either at mount time or through kernel tuning mechanism.

This caching mechanism leads to problems in following two conditions.

a. File is modified in server without updating the modification
time-stamp.
b. Granularity of the time-stamp is too large.

I was following previous discussions in the mailing list and found that
caching mechanism affected hlfsd behavior. It looks like the problem was
resolved by updating mtime on every access. But still caching will lead
to a problem if two accesses are taking place in same jiffy.

We are considering following design strategy to implement the parameter.

1. Make nfs_symlink_caching dynamically tunable using /proc and sysctl
interface.

2. Change NFS client code as follows.

A. If caching is enabled.
There are no changes. Existing caching mechanism remains intact.

B. If caching is disabled.

	i. While serving a symlink read request (nfs_getlink ()) don't
look for the requested page in page cache (read_cache_page()). Instead
always allocate a page frame (page_cache_alloc_cold()) and send a
READLINK request to the server. This allocated page frame is not added
to the cache and hence remains local to the thread of execution and is
not visible to other execution threads.

	ii. Upon receiving the response from the server, pass the data
to the user space and free the page frame. 

Please let us know your comments/opinion on this design.

Thanks and Regards
Vivek

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