> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
