From fc90547e5ba148d853cb8f9798e3bb034ee2292b Mon Sep 17 00:00:00 2001 From: Erez_Zadok Date: Wed, 19 Sep 2007 21:12:37 -0400 Subject: [PATCH] Unionfs: documentation updates/corrections Signed-off-by: Erez Zadok --- Documentation/filesystems/unionfs/concepts.txt | 4 ++-- Documentation/filesystems/unionfs/issues.txt | 2 +- Documentation/filesystems/unionfs/usage.txt | 13 +++++++------ 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/Documentation/filesystems/unionfs/concepts.txt b/Documentation/filesystems/unionfs/concepts.txt index 35ddceaed55f..37a62d858f52 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 c3a0aef23bc9..9db1d7017f35 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 23166703c4c6..d8c15de80dbe 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 . -- 2.43.0