I would like to see functionality in the kernel nfs client which permits
userspace to request that any cached data (from previous reads) be dropped
from memory. This is exactly what 'nfs_zap_caches(inode)' does in the
kernel.
I'm in the process of porting a Unix application to Linux. We use a custom
locking protocol on top of NFS. I'd originally been told that the only
special thing we required from the NFS implementation was a way to turn off
attribute caching, which is already available. However, after our locking
test suite failed on Linux, someone remembered "the other" NFS hack we've
had to make on our other ports, which involves the ability to request that
any cached data from an NFS file (present due to previous reads) be
dropped, so that a subsequent read will result in an NFS read request to
the server.
Formerly we've overloaded fsync(), but after some discussion it was
suggested to implement it as an ioctl(), rather than perverting the
meaning of fsync(). Unfortunately, there doesn't seem to be any way to
access this functionality from userspace without adding an ioctl or the
like.
The attached patch adds this functionality. I'd like to hear any
responses, including any problems with the patch, suggestions for alternate
ways I could achieve the same thing, suggestions for how to make these
changes available to our end-users in an easy-to-use and license-compliant
fashion, and most wonderful of all being told that this kind of
functionality would be included in a standard kernel somewhere down
the road.
Jeff
PS I don't understand the locking situation, but I'm the most linux-savvy
of the people working on this project so I get to write this message.
Apparently this problem crops up when a sequence like this occurs,
due to the limited resolution of mtime:
Client 1 Client 2
Write to file
Read file -> NFS request
Write to file again within 1 second
Read file -> Timestamp matches,
use cached (invalid) data
-- Jeff Epler jepler@inetnebr.com
- 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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:18 EST