> On Wed, May 23, 2007 at 12:39:25PM +0100, Al Viro wrote: > > 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> > > 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. > * 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? > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
