Unionfs: documentation updates/corrections

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>

diff --git a/Documentation/filesystems/unionfs/concepts.txt b/Documentation/filesystems/unionfs/concepts.txt
index 35ddceaed55f58dc0768eb95c8d401e3cc1e1fc5..37a62d858f52f5fca7260909f360ea896dcd6b28 100644 (file)
--- 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 c3a0aef23bc932d57bdc787f2182b56403edae85..9db1d7017f352c345552f2476025b688c7f80cd8 100644 (file)
--- 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 4ab3744a89d0d35be4f2ebc53fcd56846ccc53e6..5204614f40a90a75baafaeba6a140e1fbd4ea8fc 100644 (file)
--- 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).
 
 
 ON-DISK FORMAT (ODF)