In message <20080403010016.GU9785@xxxxxxxxxxxxxxxxxx>, Al Viro writes: > On Wed, Apr 02, 2008 at 08:47:06PM -0400, Erez Zadok wrote: > > In message <1207183329.20254.49.camel@xxxxxxxxxxxxxxxxxxxxx>, Trond Myklebust writes: > > > > > > On Thu, 2008-04-03 at 00:47 +0100, Al Viro wrote: > > [...] > > > > Again, what for? > > > > > > It allows you to get rid of the vfsmount 'argument' when opening a file, > > > which again lowers the barrier for stacking filesystems. > > > > > > As far as the filesystems themselves are concerned, the effect is to > > > enforce your assertion that file operations should not depend on the > > > namespace. > > > > I'd be delighted the day I won't have to deal with vfsmounts AT ALL in > > any stacked f/s. > > vfsmounts or the fact that any fs may be mounted in many places? I think the former. The fact that any f/s can be mounted in many places, should be fine for a stacked f/s (topology changes as we discussed before are a different problem). Since you've hinted of major vfs changes post-25, here's my take. Right now I (and to a similar extent ecryptfs too) needs to keep track of vfsmounts for various reasons: - to grab a reference so the lower filesystems/mounts won't disappear on me - to pass it to dentry_open (opening the lower file) - some fs ops pass a vfsmount (umount_begin, show_options) - some fs ops or vfs helpers require a nameidata or struct path which embed a vfsmount inside - sometimes it's ok to pass NULL for those things, sometimes it's not ok Often it also appears that a vfsmount and a dentry tuple are needed together, hence struct path. So we recently started using struct path in a few places, and using path_get/put. The need to deal with <dentry,vfsmount> pairs by hand can lead to interesting bugs, such as the recent ecryptfs bugfix which had to swap the order of a dput() and mntput() sequence. The fact that several vfs ops and helpers take different namespace-related structures (dentry, nameidata, vfsmount, path), is confusing and hard to track. Is there a way to reduce the number of those structures to 1-2 at most? For a stackable f/s, it's important the the VFS ops *and* the VFS helpers (vfs_*, path_*, dentry_open, etc.) use the same namespace structures: then there's more symmetry b/t the objects passed to a stacked f/s, and the objects it has to pass to VFS helpers (and FWIW, every such object should ideally leave a "void *private" field for f/s specific extensibility). In the longer run, is there a way that a stackable f/s could traverse the namespace below it w/o knowing or caring how they are composed (assorted r-w and r-o bind mounts and such)? Cheers, Erez. -- 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
