> On Wed, May 23, 2007 at 12:39:25PM +0100, Al Viro wrote:
quoted text
> > Then I do not understand what this mechanism could be used for, other
> > than an odd way to twist POSIX behaviour and see how much of the userland
> > would survive that.  Certainly not useful for your "look into tarball
> > as a tree", unless you seriously want to scan the entire damn fs for
> > tarballs at mount time and set up a superblock for each.  And for per-file
> > extended attributes/forks/whatever-you-call-that-abomination it also
> > obviously doesn't help, since you lose them for directories.

Someone might think of a way to make those work with directories.
Invisible directory entries, anyone?  </me ducks>

quoted text
> > IOW, what uses do you have in mind?  Complete scenario, please...
> 
> Ah... After rereading the thread you've mentioned in the very beginning,
> I think I understand what you are driving at.  However, in that case
> 	* I really don't see why bother with returning vfsmount at all.
> dentry alone is enough to create a new vfsmount, all in fs/namei.c.
> 	* the lifetime rules look fscking scary.  You call that ->enter()
> on nearly every damn lookup.  OK, so you'll recreate equivalent vfsmount,
> but...  That's a lot of allocations/freeing.  Can we do some caching and
> deal with it on memory pressure?

Hmm.

quoted text
> 	* invalidation on unlink is still an open problem.
> 	* locking in final mntput() doesn't look nice; we probably need
> a new refcounting scheme for vfsmounts to make that work.  I have a variant
> that might work here (and make life much easier for expiry logics in
> automount/shared trees, which is what it had been initially proposed for),

Which variant?  We had that "detached subtrees" thing, is that it?

quoted text
> but it still doesn't kill the need to deal with invalidation.  And
> yes, NFS still needs it (and so do all network filesystems, really).
> The question of caching is related to that.

So what's so special about invalidation?  Why not just treat
dir-on-file mounts the same as any other ref on the dentry?

Miklos
-
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