Merge branch 'nfs-for-2.6.37' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6

	- how to install and setup the Linux NFS/RDMA client and server software

nfsroot.txt

	- short guide on setting up a diskless box with NFS root filesystem.

pnfs.txt

	- short explanation of some of the internals of the pnfs client code

rpc-cache.txt

	- introduction to the caching mechanisms in the sunrpc layer.

idmapper.txt

Reference counting in pnfs:

==========================

The are several inter-related caches.  We have layouts which can

reference multiple devices, each of which can reference multiple data servers.

Each data server can be referenced by multiple devices.  Each device

can be referenced by multiple layouts.  To keep all of this straight,

we need to reference count.

struct pnfs_layout_hdr

----------------------

The on-the-wire command LAYOUTGET corresponds to struct

pnfs_layout_segment, usually referred to by the variable name lseg.

Each nfs_inode may hold a pointer to a cache of of these layout

segments in nfsi->layout, of type struct pnfs_layout_hdr.

We reference the header for the inode pointing to it, across each

outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,

LAYOUTCOMMIT), and for each lseg held within.

Each header is also (when non-empty) put on a list associated with

struct nfs_client (cl_layouts).  Being put on this list does not bump

the reference count, as the layout is kept around by the lseg that

keeps it in the list.

deviceid_cache

--------------

lsegs reference device ids, which are resolved per nfs_client and

layout driver type.  The device ids are held in a RCU cache (struct

nfs4_deviceid_cache).  The cache itself is referenced across each

mount.  The entries (struct nfs4_deviceid) themselves are held across

the lifetime of each lseg referencing them.

RCU is used because the deviceid is basically a write once, read many

data structure.  The hlist size of 32 buckets needs better

justification, but seems reasonable given that we can have multiple

deviceid's per filesystem, and multiple filesystems per nfs_client.

The hash code is copied from the nfsd code base.  A discussion of

hashing and variations of this algorithm can be found at:

http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809

data server cache

-----------------

file driver devices refer to data servers, which are kept in a module

level cache.  Its reference is held over the lifetime of the deviceid

pointing to it.

config NFS_V4_1

	bool "NFS client support for NFSv4.1 (EXPERIMENTAL)"

	depends on NFS_V4 && EXPERIMENTAL

	depends on NFS_FS && NFS_V4 && EXPERIMENTAL

	select PNFS_FILE_LAYOUT

	help

	  This option enables support for minor version 1 of the NFSv4 protocol

	  (draft-ietf-nfsv4-minorversion1) in the kernel's NFS client.

	  (RFC 5661) in the kernel's NFS client.

	  If unsure, say N.

config PNFS_FILE_LAYOUT

	tristate

config ROOT_NFS

	bool "Root file system on NFS"

	depends on NFS_FS=y && IP_PNP

			   delegation.o idmap.o \

			   callback.o callback_xdr.o callback_proc.o \

			   nfs4namespace.o

nfs-$(CONFIG_NFS_V4_1)	+= pnfs.o

nfs-$(CONFIG_SYSCTL) += sysctl.o

nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o

obj-$(CONFIG_PNFS_FILE_LAYOUT) += nfs_layout_nfsv41_files.o

nfs_layout_nfsv41_files-y := nfs4filelayout.o nfs4filelayoutdev.o

	if (delegation == NULL)

		return 0;

	/* seqid is 4-bytes long */

	if (((u32 *) &stateid->data)[0] != 0)

	if (stateid->stateid.seqid != 0)

		return 0;

	if (memcmp(&delegation->stateid.data[4], &stateid->data[4],

		   sizeof(stateid->data)-4))

	if (memcmp(&delegation->stateid.stateid.other,

		   &stateid->stateid.other,

		   NFS4_STATEID_OTHER_SIZE))

		return 0;

	return 1;