Documentation: nfs: convert pnfs.txt to ReST

Convert pnfs.txt to ReST. Content remains mostly unchanged.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Link: https://lore.kernel.org/r/20200129044917.566906-2-dwlsalmeida@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index 386eaad008b2001379080a2cbbe92bb21c891861..45d791905e9176b29e950649df91a22c810f6070 100644 (file)
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -51,3 +51,4 @@ Documentation for filesystem implementations.
    overlayfs
    virtiofs
    vfat
+   nfs/index

diff --git a/Documentation/filesystems/nfs/index.rst b/Documentation/filesystems/nfs/index.rst
new file mode 100644 (file)
index 0000000..d19ba59
--- /dev/null
+++ b/Documentation/filesystems/nfs/index.rst
@@ -0,0 +1,9 @@
+===============================
+NFS
+===============================
+
+
+.. toctree::
+   :maxdepth: 1
+
+   pnfs

diff --git a/Documentation/filesystems/nfs/pnfs.rst b/Documentation/filesystems/nfs/pnfs.rst
new file mode 100644 (file)
index 0000000..7c470ec
--- /dev/null
+++ b/Documentation/filesystems/nfs/pnfs.rst
@@ -0,0 +1,78 @@
+==========================
+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 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 `here.
+<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.
+
+lseg
+====
+
+lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
+bit which holds it in the pnfs_layout_hdr's list.  When the final lseg
+is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
+bit is set, preventing any new lsegs from being added.
+
+layout drivers
+==============
+
+PNFS utilizes what is called layout drivers. The STD defines 4 basic
+layout types: "files", "objects", "blocks", and "flexfiles". For each
+of these types there is a layout-driver with a common function-vectors
+table which are called by the nfs-client pnfs-core to implement the
+different layout types.
+
+Files-layout-driver code is in: fs/nfs/filelayout/.. directory
+Blocks-layout-driver code is in: fs/nfs/blocklayout/.. directory
+Flexfiles-layout-driver code is in: fs/nfs/flexfilelayout/.. directory
+
+blocks-layout setup
+===================
+
+TODO: Document the setup needs of the blocks layout driver

diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt
deleted file mode 100644 (file)
index 80dc0bd..0000000
--- a/Documentation/filesystems/nfs/pnfs.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-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 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.
-
-lseg
-----
-lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
-bit which holds it in the pnfs_layout_hdr's list.  When the final lseg
-is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
-bit is set, preventing any new lsegs from being added.
-
-layout drivers
---------------
-
-PNFS utilizes what is called layout drivers. The STD defines 4 basic
-layout types: "files", "objects", "blocks", and "flexfiles". For each
-of these types there is a layout-driver with a common function-vectors
-table which are called by the nfs-client pnfs-core to implement the
-different layout types.
-
-Files-layout-driver code is in: fs/nfs/filelayout/.. directory
-Blocks-layout-driver code is in: fs/nfs/blocklayout/.. directory
-Flexfiles-layout-driver code is in: fs/nfs/flexfilelayout/.. directory
-
-blocks-layout setup
--------------------
-
-TODO: Document the setup needs of the blocks layout driver