From 07e2a585a86c3de0f664ac5b522d6d3e90c55d54 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 35ddceaed55..37a62d858f5 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 c3a0aef23bc..9db1d7017f3 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 23166703c4c..d8c15de80db 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