From: Mike Waychison <michael.waychison@sun.com>
To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: raven@themaw.net
Subject: [PATCH 9/28] VFS: Give sane expiry semantics
Date: Mon, 25 Oct 2004 10:43:02 -0400 [thread overview]
Message-ID: <10987153821176@sun.com> (raw)
In-Reply-To: <10987153522992@sun.com>
This patch changes the semantics of expiry slightly when dealing with stuff
like --move, --bind and --rbind. The newly added file
Documentation/filesystems/expire_semantics.txt describes how it works.
Signed-off-by: Mike Waychison <michael.waychison@sun.com>
---
Documentation/filesystems/expire_semantics.txt | 184 +++++++++++++++++++++++++
fs/namespace.c | 26 ++-
2 files changed, 202 insertions(+), 8 deletions(-)
Index: linux-2.6.9-quilt/fs/namespace.c
===================================================================
--- linux-2.6.9-quilt.orig/fs/namespace.c 2004-10-22 17:17:37.121820768 -0400
+++ linux-2.6.9-quilt/fs/namespace.c 2004-10-22 17:17:37.770722120 -0400
@@ -178,13 +178,22 @@ static int can_expire(struct vfsmount *r
}
static struct vfsmount *
-clone_mnt(struct vfsmount *old, struct dentry *root)
+clone_mnt(struct vfsmount *old, struct dentry *root, int keep_expiry)
{
struct super_block *sb = old->mnt_sb;
struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
if (mnt) {
- mnt->mnt_flags = old->mnt_flags & ~MNT_CHILDEXPIRE;
+ if (keep_expiry) {
+ mnt->mnt_flags = old->mnt_flags;
+ if (!list_empty(&old->mnt_expire)) {
+ spin_lock(&vfsmount_lock);
+ list_add_tail(&mnt->mnt_expire, &expiry_list);
+ spin_unlock(&vfsmount_lock);
+ }
+ } else {
+ mnt->mnt_flags = old->mnt_flags & ~MNT_CHILDEXPIRE;
+ }
atomic_inc(&sb->s_active);
mnt->mnt_sb = sb;
mnt->mnt_root = dget(root);
@@ -589,13 +598,14 @@ lives_below_in_same_fs(struct dentry *d,
}
}
-static struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry)
+static struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
+ int keep_expiry)
{
struct vfsmount *res, *p, *q, *r, *s;
struct list_head *h;
struct nameidata nd;
- res = q = clone_mnt(mnt, dentry);
+ res = q = clone_mnt(mnt, dentry, keep_expiry);
if (!q)
goto Enomem;
q->mnt_mountpoint = mnt->mnt_mountpoint;
@@ -614,7 +624,7 @@ static struct vfsmount *copy_tree(struct
p = s;
nd.mnt = q;
nd.dentry = p->mnt_mountpoint;
- q = clone_mnt(p, p->mnt_root);
+ q = clone_mnt(p, p->mnt_root, keep_expiry);
if (!q)
goto Enomem;
spin_lock(&vfsmount_lock);
@@ -692,9 +702,9 @@ static int do_loopback(struct nameidata
if (check_mnt(nd->mnt) && (!recurse || check_mnt(old_nd.mnt))) {
err = -ENOMEM;
if (recurse)
- mnt = copy_tree(old_nd.mnt, old_nd.dentry);
+ mnt = copy_tree(old_nd.mnt, old_nd.dentry, 0);
else
- mnt = clone_mnt(old_nd.mnt, old_nd.dentry);
+ mnt = clone_mnt(old_nd.mnt, old_nd.dentry, 0);
}
if (mnt) {
@@ -1197,7 +1207,7 @@ int copy_namespace(int flags, struct tas
down_write(&tsk->namespace->sem);
/* First pass: copy the tree topology */
- new_ns->root = copy_tree(namespace->root, namespace->root->mnt_root);
+ new_ns->root = copy_tree(namespace->root, namespace->root->mnt_root, 1);
if (!new_ns->root) {
up_write(&tsk->namespace->sem);
kfree(new_ns);
Index: linux-2.6.9-quilt/Documentation/filesystems/expire_semantics.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.9-quilt/Documentation/filesystems/expire_semantics.txt 2004-10-22 17:17:37.775721360 -0400
@@ -0,0 +1,184 @@
+Mountpoint Expiry Semantics
+===========================
+
+In order to implement an autofs system as described in 'Towards a Modern Autofs'
+(ftp://ftp-eng.cobalt.com/pub/whitepapers/autofs/towards_a_modern_autofs.txt), a
+VFS-native expiry system needs to be designed and implemented. This document
+attempts to summarize the expiry requirements the autofs design requires and
+lays out a set of expiry semantics.
+
+Requirements
+------------
+
+The following is a set of functions we wish to be able to perform with the
+expiry system.
+
+ - We need to be able to arbitrarily specify timeouts for all expiries.
+ - The ability to set an arbitrary timeout at mount-time.
+ - The ability to change a timeout (via a remount)
+ - The ability to remount a given filesystem without affecting the expiry
+ settings.
+ - The ability to disable an expiry of a mountpoint.
+ - We need to be able to expire a single mountpoint.
+ - We need to be able to expire a tree of mountpoints in an atomic fashion.
+ This is required to support lazy-mounting as this is done by nesting direct
+ mount triggers within expiring NFS filesystems.
+ - The ability to mark a sub-tree as expirying all child mountpoints in
+ unison.
+ - The ability to remount individual mountpoints within a sub-tree (children
+ as well as the root mountpoint of the sub-tree) without affecting the
+ expiry settings for that sub-tree.
+ - The ability to disable expiry of a sub-tree.
+ - The semantic that any added mountpoints into a sub-tree after the sub-tree
+ has been marked to expire will block the expire of the sub-tree.
+ - We need to be able to read expiry settings.
+ - The ability to read expiry settings for an individual mountpoint expiry.
+ - The ability to read expiry settings for a sub-tree (by looking at the root
+ mountpoint of the sub-tree).
+ - The ability to identify whether a given mountpoint is part of a sub-tree
+ expiry.
+
+Ticks
+-----
+
+Ticks are meant as a way to specify the amount of time of inactivity that should
+occur before mountpoints expire. Ticks will by default be 10 seconds long, and
+will be configurable via a sysctl interface. The sysctl interface will be
+represented in terms of USER_HZ. The length of a tick is left configurable as
+calculating expiry may become a tedious task on larger system where less
+frequent expiry checks may be more desirable.
+
+Policies
+--------
+
+In order to fulfill the requirements outlined above, we define a new attribute
+to mountpoints called the expiry policy. Each policy may define a set of
+policy-related attributes.
+
+
+ 'NOEXPIRE' - This is the default expiry policy for any given mountpoint.
+ It signifies that this mountpoint will neither expire nor is it part of a
+ sub-tree expiry.
+
+ This policy has no attributes.
+
+ 'EXPIRE' - This policy means that the given mountpoint is set to
+ eventually expire. It may be an individual mountpoint expiry, or may be
+ the root of a sub-tree that will expire.
+
+ Attribute 'ticks' - This is the number of ticks that must pass of
+ inactive use before the mountpoint will expire. This value is a non-zero
+ positive integer. For more information on 'ticks', see above: 'Ticks'.
+
+ 'SUBTREEEXPIRE' - This policy specifies that the mountpoint in question is
+ part of a larger sub-tree expiry.
+
+
+Policy transitions
+------------------
+
+Certain rules need to apply when the policy for a mountpoint is changed.
+Following is a description of what occurs when a policy has changed for all
+possible transitions:
+
+NOEXPIRE -> EXPIRE
+ A mountpoint that was previously not marked for expiry is now marked for
+ expiry. If the attribute value for 'ticks' is not a positive integer, then
+ this transition fails. This transition also fails automatically for the
+ true-root of a namespace.
+
+NOEXPIRE -> SUBTREEEXPIRE
+ A mountpoint that was not previously set to expire will now expire as part of
+ it's parent expiry. This transition fails if the policy of the immediate
+ parent mointpoint of the mountpoint in question is not either EXPIRE or
+ SUBTREEEXPIRE.
+
+EXPIRE -> NOEXPIRE
+ A mountpoint that was set to expire will no longer expire. Any immediate
+ child mountpoints whose policy is SUBTREEEXPIRE transitions to NOEXPIRE, as
+ described below.
+
+EXPIRE -> SUBTREEEXPIRE
+ This is an invalid policy transition. Instead, a transition from EXPIRE to
+ NOEXPIRE followed by a transition from NOEXPIRE to SUBTREEEXPIRE should be
+ performed.
+
+SUBTREEEXPIRE -> NOEXPIRE
+ A mountpoint that was marked as being part of a sub-tree expiry no longer is
+ part of that expiry. Any immediate child mountpoints of the mountpoint in
+ question that also have the SUBTREEEXPIRE policy will recursively receive an
+ implied SUBTREEEXPIRE -> NOEXPIRE transition.
+
+SUBTREEEXPIRE -> EXPIRE
+ This is an invalid policy transition. Instead, a transition from
+ SUBTREEEXPIRE to NOEXPIRE followed by a transition from NOEXPIRE to EXPIRE
+ should be performed.
+
+Note: Transitions between SUBTREEXPIRE and EXPIRE are invalid in order to
+simplify the corner cases of a failed transition. Transitioning to
+SUBTREEEXPIRE is the only path where things can actually fail (eg: parent
+mountpoint is NOEXPIRE), and trasitioning from EXPIRE may alter children
+mountpoints of the mountpoint in question. This implied loss of information is
+more explicit when you must transition to NOEXPIRE as an intermediate.
+
+Mount Operations
+----------------
+
+The following are a list of mount operations that may occur along with a
+description of implied policy changes that may occur.
+
+
+Mount Move:
+
+ A mountpoint is moved from one location to another. If the policy was:
+
+ NOEXPIRE - The policy remains NOEXPIRE
+ EXPIRE - The policy remains EXPIRE
+ SUBTREEEXPIRE - The policy for the given mountpoint transitions to NOEXPIRE
+
+Mount Bind:
+
+ There are several variants on mount bind operations:
+
+ - Single bind of from a mountpoint to another location. Only one filesystem
+ is actually available in the new location after the bind.
+ - Single bind of a directory (not a mountpoint) to another location. This
+ is similar to the previous scenario however the root directory of the
+ new mountpoint is a sub-directory of the original mountpoint.
+ - A recursive bind from a mountpoint to another location.
+ - A recursive bind from a directory that isn't a mountpoint to another
+ location.
+
+ In all cases, all newly created mountpoints are created with the NOEXPIRE
+ policy. This allows a userspace application to arbitrarily determine what it
+ wishes to do with the expiry policy on the bind.
+
+Remount:
+
+ All filesystems remounts should not effect the expiry policy. That is, the
+ policy and policy attributes should remain the same across a mountpoint
+ remount unless the policy itself was changed.
+
+Namespace Creation:
+
+ When a namespace is created, it is derived from the parenting namespace. A
+ namespace begins it's life as a complete clone and as such, any mountpoints in
+ that namespace should inherit the expiry policies set at the time of namespace
+ creation.
+
+Detaching Mountpoints (umount -l):
+
+ Lazy unmounting is a particular case as the mointpoints in question are still
+ accessible, however not navigeable from the root directory. Currently, when a
+ lazy unmount occurs on a sub-tree, all elements of that sub-tree are torn
+ apart and their resources freed once all references into that given mountpoint
+ are released. In this case, all mountpoints should transition their expiry
+ policy to NOEXPIRE.
+
+ In a future case where a lazy unmount of a sub-tree does not result in the
+ sub-tree being torn apart (so that it may possibly be reattached elsewhere),
+ the root of this sub-tree's policy should transition as follows:
+
+ - EXPIRE -> EXPIRE
+ - NOEXPIRE -> NOEXPIRE
+ - SUBTREEEXPIRE -> NOEXPIRE
next prev parent reply other threads:[~2004-10-25 15:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-25 14:38 [PATCH 0/28] Autofs NG Patchset 0.2 Mike Waychison
2004-10-25 14:39 ` [PATCH 1/28] VFS: Unexport umount_tree Mike Waychison
2004-10-25 14:39 ` [PATCH 2/28] VFS: mnt_fslink -> mnt_expire Mike Waychison
2004-10-25 14:40 ` [PATCH 3/28] VFS: Move expiry into vfs Mike Waychison
2004-10-25 14:40 ` [PATCH 4/28] VFS: Stat shouldn't stop expire Mike Waychison
2004-10-25 14:41 ` [PATCH 5/28] VFS: Make expiry timeout configurable Mike Waychison
2004-10-25 14:41 ` [PATCH 6/28] VFS: Make expiry recursive Mike Waychison
2004-10-25 14:42 ` [PATCH 7/28] AFS: Update AFS to use new expiry interface Mike Waychison
2004-10-25 14:42 ` [PATCH 8/28] VFS: Remove MNT_EXPIRE support Mike Waychison
2004-10-25 14:43 ` Mike Waychison [this message]
2004-10-25 14:43 ` [PATCH 10/28] VFS: Move next_mnt() Mike Waychison
2004-10-25 14:44 ` [PATCH 11/28] VFS: Allow for detachable subtrees Mike Waychison
2004-10-25 14:44 ` [PATCH 12/28] VFS: Remove (now bogus) check_mnt Mike Waychison
2004-10-25 14:45 ` [PATCH 13/28] VFS: Introduce soft reference counts Mike Waychison
2004-10-25 15:25 ` Christoph Hellwig
2004-10-25 15:35 ` [PATCH 14/28] VFS: Introduce Mountpoint file descriptors (resend) Mike Waychison
2004-10-25 17:20 ` [PATCH 13/28] VFS: Introduce soft reference counts Mika Penttilä
2004-10-25 17:25 ` Mike Waychison
2004-10-25 17:25 ` Mike Waychison
2004-10-25 17:52 ` Mika Penttilä
2004-10-25 17:52 ` Mika Penttilä
2004-10-25 17:56 ` [PATCH 11/28] VFS: Allow for detachable subtrees (resend) Mike Waychison
2004-10-25 15:09 ` [PATCH 12/28] VFS: Remove (now bogus) check_mnt Christoph Hellwig
2004-10-25 15:15 ` Mike Waychison
2004-10-25 15:04 ` [PATCH 8/28] VFS: Remove MNT_EXPIRE support Christoph Hellwig
2004-10-25 15:12 ` Mike Waychison
2004-10-25 15:16 ` Christoph Hellwig
2004-10-25 15:30 ` Mike Waychison
2004-10-25 17:16 ` Mike Waychison
2004-10-25 17:29 ` Mike Waychison
2004-10-25 15:04 ` [PATCH 6/28] VFS: Make expiry recursive Christoph Hellwig
2004-10-26 10:27 ` [PATCH 4/28] VFS: Stat shouldn't stop expire Christoph Hellwig
2004-10-27 18:36 ` Mike Waychison
2004-10-25 14:59 ` [PATCH 3/28] VFS: Move expiry into vfs Christoph Hellwig
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10987153821176@sun.com \
--to=michael.waychison@sun.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.