Browse Prior Art Database

A method to selectively refresh file pages in an NFS client Disclosure Number: IPCOM000237211D
Publication Date: 2014-Jun-09
Document File: 3 page(s) / 264K

Publishing Venue

The Prior Art Database


A method to selectively refresh file pages in an Network File System (NFS) client is disclosed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 01 of 3

A method to selectively refresh file pages in an NFS client

Disclosed is a method to selectively refresh file pages in an Network File System (NFS) client.

In NFS setups involving real-time data processing, it is typical to have several NFS clients that access the files as read-only, with typically only 1 or 2 clients (master clients) making modifications to files. For performance improvement NFS clients typically cache the file in memory as Virtual Memory Manager (VMM) pages. When the master client makes a small change to the file on the NFS server, this causes the other NFS clients to flush all the cached data (and refetch the data as needed). Depending on the size of the cached data, this flush operation can take a long time and causes other operations related to this file to block.

The disclosed method allows the NFS clients to learn which portion of the file changed, so that it does not need to flush the entire VMM cache for that file. By enabling the NFS client to learn which section of the file changed, the client can now just invalidate those particular VMM page(s) and not have to flush the entire file. With this method, the NFS client will be able to perform significantly better in such scenarios.

Two solutions to enable an NFS client to learn which portion of the file are depicted in Figure 1.
Registered clients: A client is registered with the NFS server. In this scheme, the NFS server pro-actively notifies the NFS client about changes to the files of interest.

Unregistered clients: These NFS clients do not support the pro-active notification by NFS servers. Instead, they query the NFS server on as needed basis in order to receive information about changes to the file.

The disclosed method works with both NFSv3 and NFSv4. Though NFSv4 is the most current version, the reality is NFSv3 is much more prevalent and has a much bigger market penetration, and thus a solution that works for NFSv3 is quite attractive.

Figure 1

An example embodiment for notifying registered clients is depicted in Figure 2.

A kernel extension, CHGNOTIFY, is installed on both the NFS client and server systems. The CHGNOTIFY driver on the NFS client registers and listens on a pre-established multicast address. An Application Programming Interface (API) is be provided whereby the interested NFS clients can register with the CHGNOTIFY driver on the NFS server.

The NFS driver is modified to allow the NFS server code to interface with the CHGNOTIFY driver, say server_notify (File, Offset, Length). Similarly, an interface is also be provided for the CHGNOTIFY driver to interface with the NFS client code, say client_notify (File, Offset, Length).

When the NFS server receives a WRITE RPC request, it invokes the server_notify() API with the Filehandle, Offset, and the Length arguments. The CHGNOTIFY driver then sends out a multicast message to the registered clients passing the (File, Offset, Length) information.

The CHGNOTIFY driver on the NFS clients then...