Re: [RFC PATCH] file as directory

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Miklos Szeredi <miklos@...>
Cc: <linux-kernel@...>, <linux-fsdevel@...>, <akpm@...>, <torvalds@...>
Date: Wednesday, May 23, 2007 - 9:51 am

On Wed, May 23, 2007 at 03:01:38PM +0200, Miklos Szeredi wrote:

Not unless you manage to get working union-mount [*NOT* unionfs]
 

Umm...  It is related to detached subtrees, but I'm not sure if it is what
you are thinking about.

Short version of the story: new counter (mnt_busy) that would be defined
in the following way: the number of external references (not due to the
vfsmount tree structure or from namespace to root) + the number of
children that have non-zero ->mnt_busy.  And a per-vfsmount flag ("goner").

The rules for handling ->mnt_busy:
	* duplicating external reference: increment m->mnt_busy
	* getting from m to child: increment child->mnt_busy, if it went
from 0 to non-zero - increment m->mnt_busy as well (that's done under
vfsmount_lock, so we can safely check for zero here).
	* getting from m to parent: increment parent->mnt_busy.
	* dropping external reference: decrement m->mnt_busy; if it's still
non-zero, we are done.  If it's zero, we are in for some work (and had
acquired vfsmount_lock by atomic_dec_and_lock()).  Here's what we do:
		* go through ancestors, decrementing ->mnt_busy, until we
		  hit the root or get to one with ->mnt_busy staying
		  non-zero.
		* find the most remote ancestor that has zero ->mnt_busy
		  and is marked as goner (might be m itself).
		* if no such beast exists, we are done.
		* otherwise, detach the subtree rooted in that ancestor
		  from its parent (if any) and unhash its root (if hashed).
		  Now there is no external references to any vfsmount in that
		  subtree.
		* now we can kill all vfsmounts in that subtree.
	* detaching m from parent: nothing; we trade a busy child of parent
for new external reference to parent.
	* lazy umount: in addition to detaching everything from parents
and dropping resulting external references to parents, mark everything
in the subtree as goners.
	* normal umount: check ->mnt_busy *and* lack of children, detach,
mark as goner, drop resulting external reference to parent.
	* fun new stuff - umount of intact subtree: detach the subtree from
parent, do *not* dissolve it, mark everything in subtree as goners.  If
something we mark as goner is not busy, we can kill it and all its descendents.
The subtree will be shrinking as its pieces lose external references.
	* check for expirability: "we hold an external reference to m and
m->mnt_busy is 1".  No need to look into children, etc.
	* your vfsmounts: simply mark them goners from the very beginning.
 

Because of the case of having something mounted in that subtree.  The
current code doesn't even try to evict such stuff.  NFS *does*, but
it's not in position to do that decently (not NFS fault, it's just that
we don't have the data needed for it).

Note that one problem we used to have back then is gone - namely, per-namespace
semaphores.  It's a global semaphore now, so we *can* do cross-namespace
rogering of mount trees without that kind of locking horrors.

What we really need is "go through dentry subtree, try to evict everything
we can, for anything that has stuff mounted on it go through all such
vfsmounts and kick them and all their descendents out".  That's what should
happen on invalidation.  From generic code, so that NFS wouldn't have to
bother.

And _that_ is what we could call from ->unlink() on your inode - would take
care of submounts.

Note that I'm not all that happy about this scheme; we might make it work,
but I still want to see a good use scenario for that kind of stuff.
Invalidation logics is a separate story - it's simply needed for existing
stuff; that area sucks *badly*, regardless of adding these hybrid objects.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC PATCH] file as directory, Miklos Szeredi, (Tue May 22, 2:48 pm)
Re: [RFC PATCH] file as directory, Jaroslav Sykora, (Wed May 23, 9:20 am)
Re: [RFC PATCH] file as directory, Jan Engelhardt, (Wed May 23, 8:01 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 5:51 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 6:09 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 6:24 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 6:24 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 6:40 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 7:39 am)
Re: [RFC PATCH] file as directory, Ph. Marek, (Wed May 23, 9:23 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 9:54 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 8:16 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 9:01 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 9:51 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 10:32 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 11:06 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 11:25 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 11:37 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 11:55 am)
Re: [RFC PATCH] file as directory, Shaya Potter, (Tue May 22, 7:26 pm)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 2:39 am)
Re: [RFC PATCH] file as directory, Al Viro, (Tue May 22, 6:10 pm)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 2:36 am)
Re: [RFC PATCH] file as directory, Pavel Machek, (Thu May 24, 8:07 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Mon May 28, 10:43 am)
Re: [RFC PATCH] file as directory, Jan Blunck, (Wed May 23, 5:21 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 5:35 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 3:03 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 3:19 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 3:36 am)
Re: [RFC PATCH] file as directory, Trond Myklebust, (Wed May 23, 8:34 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 8:40 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 4:05 am)
Re: [RFC PATCH] file as directory, Jan Blunck, (Wed May 23, 5:16 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 5:28 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 4:29 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 5:03 am)
Re: [RFC PATCH] file as directory, Al Viro, (Wed May 23, 5:58 am)
Re: [RFC PATCH] file as directory, Miklos Szeredi, (Wed May 23, 6:14 am)