File handling

Read-only cache support

The appliance supports caching of NFS requests and read-only operations. Read-only data is written to disk on the appliance and cached to serve future client requests. All other operations are passed through or proxied to the origin server. The appliance proxies any operation that modifies the state of the file system, for example, writing to a file or creating a directory.

File handles

The distributed NFS appliance caches objects by NFS file handle as opposed to file name. An NFS file handle is a reference to a file or a directory that is independent of a file name. All NFS operations use a file handle to identify the file or directory to which an operation applies.

The file handle, an opaque piece of data, is created by and returned from an NFS server in response to NFS requests. Only the server can interpret the data contained within that file handle. File handles provide the server flexibility in determining the most efficient way to reference a file.

A file handle is a persistent reference, which means that it remains valid until the file or directory is removed from the server.

Clients use file handles to refer to both files and directories on which they want to perform NFS operations. The operations most commonly used are LOOKUP, GETATTR, and ACCESS. Some common NFS operations include those shown in the following table.

NFS operation	Description
`GETATTR` <fh>	Returns the attributes of the file specified by the file handle
`READ` <fh, offset, count`>`	Reads the part of a file specified by the file handle
`WRITE` <fh, offset, count, data>	Writes data to a file.
`READDIR` <fh>	Returns a list of all of the files contained in a directory
`LOOKUP` (fh, name)	Returns a file handle for a file or directory with a certain name found in a directory specified by a directory file handle in the request
`ACCESS` (fh, access)	Returns permission checking of future requests (NFS 3 only)

Caching granularity

Cache space is expected to be significantly smaller than the size of the source file system. The appliance administers its own cache space by caching only parts of files.

Caching at a block level:

The appliance caches at a block level. Caching is performed at a minimum of 4K block granularity. This means that, for example, if a client issues a read for three blocks of a file, the appliance is able to cache and serve hits on these three blocks of the file, even if the file itself is much larger than three blocks. Caching at this granularity results in efficient use of disk space and maximizes hits for "hot" objects, that is, objects that are frequently requested.

Data consistency

The appliance supports varying levels of caching and varying levels of data consistency, depending on the data source.

The appliance acts as a sparse volume, which means that the appliance starts out empty and is populated as responses to client requests are cached. Only the data that has been requested by a user is cached. It is possible to have a file's attributes cached but no data for the file.

Cached objects remain on the appliance as long as they remain consistent with the origin server. Server-side consistency is achieved in the following ways:

Data is cached only when it is returned from the origin server.
Data is invalidated on the appliance when any operation associated with a source file modification on the origin server is proxied through the appliance.
Before the appliance serves a hit, based on consistency settings, the cached file attributes are verified with source file attributes. If the file has changed, it is discarded and the appliance forces a cache miss.
Note
NFS version 3 introduced a new subset of file attributes for verifying data consistency. Therefore, cache hit rates and overall performance for NFS version 3 is higher than that of NFS version 2.

Invalidation at a file level:

Although caching granularity occurs at a block level, invalidation of cached data occurs at a file level. When the cache discovers that the attributes of the file have changed, it will eject the entire file. This means that if one block of a hundred block file is changed, the entire file will be ejected.