GIT: unionfs2-2.6.27.y: Unionfs: documentation updates/corrections

[Erez Zadok]

commit f2c2fc75cfd5ae74965b54adf9716e0ddf82f0ea
Author: Erez_Zadok <ezk at cs.sunysb.edu>
Date:   Wed Sep 19 21:12:37 2007 -0400

    Unionfs: documentation updates/corrections
    
    Signed-off-by: Erez Zadok <ezk at cs.sunysb.edu>

diff --git a/Documentation/filesystems/unionfs/concepts.txt b/Documentation/filesystems/unionfs/concepts.txt
index 35ddcea..37a62d8 100644
--- a/Documentation/filesystems/unionfs/concepts.txt
+++ b/Documentation/filesystems/unionfs/concepts.txt
@@ -1,4 +1,4 @@
-Unionfs 2.0 CONCEPTS:
+Unionfs 2.1 CONCEPTS:
 =====================
 
 This file describes the concepts needed by a namespace unification file
@@ -92,7 +92,7 @@ Maintaining Invariants:
 The way Unionfs ensures cache coherency is as follows.  At each entry point
 to a Unionfs file system method, we call a utility function to validate the
 primary objects of this method.  Generally, we call unionfs_file_revalidate
-on open files, and __Unionfs_d_revalidate_chain on dentries (which also
+on open files, and __unionfs_d_revalidate_chain on dentries (which also
 validates inodes).  These utility functions check to see whether the upper
 Unionfs object is in sync with any of the lower objects that it represents.
 The checks we perform include whether the Unionfs superblock has a newer
diff --git a/Documentation/filesystems/unionfs/issues.txt b/Documentation/filesystems/unionfs/issues.txt
index c3a0aef..9db1d70 100644
--- a/Documentation/filesystems/unionfs/issues.txt
+++ b/Documentation/filesystems/unionfs/issues.txt
@@ -17,7 +17,7 @@ KNOWN Unionfs 2.1 ISSUES:
    an upper object, and then a lower object, in a strict order to avoid
    locking problems; in addition, Unionfs, as a fan-out file system, may
    have to lock several lower inodes.  We are currently looking into Lockdep
-   to see how to make it aware of stackable file systems.  In the mean time,
+   to see how to make it aware of stackable file systems.  In the meantime,
    if you get any warnings from Lockdep, you can safely ignore them (or feel
    free to report them to the Unionfs maintainers, just to be sure).
 
diff --git a/Documentation/filesystems/unionfs/usage.txt b/Documentation/filesystems/unionfs/usage.txt
index 2316670..d8c15de 100644
--- a/Documentation/filesystems/unionfs/usage.txt
+++ b/Documentation/filesystems/unionfs/usage.txt
@@ -79,7 +79,7 @@ CACHE CONSISTENCY
 =================
 
 If you modify any file on any of the lower branches directly, while there is
-a Unionfs 2.0 mounted above any of those branches, you should tell Unionfs
+a Unionfs 2.1 mounted above any of those branches, you should tell Unionfs
 to purge its caches and re-get the objects.  To do that, you have to
 increment the generation number of the superblock using the following
 command:
@@ -87,11 +87,12 @@ command:
 # mount -t unionfs -o remount,incgen none MOUNTPOINT
 
 Note that the older way of incrementing the generation number using an
-ioctl, is no longer supported in Unionfs 2.0.  Ioctls in general are not
-encouraged.  Plus, an ioctl is per-file concept, whereas the generation
-number is a per-file-system concept.  Worse, such an ioctl requires an open
-file, which then has to be invalidated by the very nature of the generation
-number increase (read: the old generation increase ioctl was pretty racy).
+ioctl, is no longer supported in Unionfs 2.0 and newer.  Ioctls in general
+are not encouraged.  Plus, an ioctl is per-file concept, whereas the
+generation number is a per-file-system concept.  Worse, such an ioctl
+requires an open file, which then has to be invalidated by the very nature
+of the generation number increase (read: the old generation increase ioctl
+was pretty racy).
 
 
 For more information, see <http://unionfs.filesystems.org/>.