LKML Archive on
help / color / mirror / Atom feed
From: Erez Zadok <>
	Erez Zadok <>
Subject: [PATCH 03/17] Unionfs: document behavior when the lower topology changes
Date: Sat, 16 Feb 2008 21:57:12 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Signed-off-by: Erez Zadok <>
 Documentation/filesystems/unionfs/concepts.txt |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/filesystems/unionfs/concepts.txt b/Documentation/filesystems/unionfs/concepts.txt
index bed69bd..8d9a1c5 100644
--- a/Documentation/filesystems/unionfs/concepts.txt
+++ b/Documentation/filesystems/unionfs/concepts.txt
@@ -210,4 +210,17 @@ there's a lot of concurrent activity on both the upper and lower objects,
 for the same file(s).  Lastly, this delayed time attribute detection is
 similar to how NFS clients operate (e.g., acregmin).
+Finally, there is no way currently in Linux to prevent lower directories
+from being moved around (i.e., topology changes); there's no way to prevent
+modifications to directory sub-trees of whole file systems which are mounted
+read-write.  It is therefore possible for in-flight operations in unionfs to
+take place, while a lower directory is being moved around.  Therefore, if
+you try to, say, create a new file in a directory through unionfs, while the
+directory is being moved around directly, then the new file may get created
+in the new location where that directory was moved to.  This is a somewhat
+similar behaviour in NFS: an NFS client could be creating a new file while
+th NFS server is moving th directory around; the file will get successfully
+created in the new location.  (The one exception in unionfs is that if the
+branch is marked read-only by unionfs, then a copyup will take place.)
 For more information, see <>.

  parent reply	other threads:[~2008-02-17  2:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-17  2:57 [GIT PULL -mm] 00/17 Unionfs updates/fixes/cleanups Erez Zadok
2008-02-17  2:57 ` [PATCH 01/17] Unionfs: grab lower super_block references Erez Zadok
2008-02-17  2:57 ` [PATCH 02/17] Unionfs: ensure consistent lower inodes types Erez Zadok
2008-02-17  2:57 ` Erez Zadok [this message]
2008-02-17  2:57 ` [PATCH 04/17] Unionfs: uninline unionfs_copy_attr_times and unionfs_copy_attr_all Erez Zadok
2008-02-17  2:57 ` [PATCH 05/17] Unionfs: initialize path_save variable Erez Zadok
2008-02-17  2:57 ` [PATCH 06/17] Unionfs: extend dentry branch configuration lock in open Erez Zadok
2008-02-17  2:57 ` [PATCH 07/17] Unionfs: follow_link locking fixes Erez Zadok
2008-02-17  2:57 ` [PATCH 08/17] Unionfs: improve debugging in copy_attr_times Erez Zadok
2008-02-17  2:57 ` [PATCH 09/17] Unionfs: revalidation code cleanup and refactoring Erez Zadok
2008-02-17  2:57 ` [PATCH 10/17] Unionfs: factor out revalidation routine Erez Zadok
2008-02-17  2:57 ` [PATCH 11/17] Unionfs: lock parents' branch configuration fixes Erez Zadok
2008-02-17  2:57 ` [PATCH 12/17] Unionfs: branch management/configuration fixes Erez Zadok
2008-02-17  2:57 ` [PATCH 13/17] Unionfs: use dget_parent in revalidation code Erez Zadok
2008-02-17  2:57 ` [PATCH 14/17] Unionfs: stop using iget() and read_inode() Erez Zadok
2008-02-17  2:57 ` [PATCH 15/17] Unionfs: embed a struct path into struct nameidata instead of nd dentrymnt Erez Zadok
2008-02-17  2:57 ` [PATCH 16/17] Unionfs: use the new path_put Erez Zadok
2008-02-17  2:57 ` [PATCH 17/17] VFS/Unionfs: use generic path_get/path_put functions Erez Zadok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 03/17] Unionfs: document behavior when the lower topology changes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).