Re: [patch 01/10] vfs: add path_create() and path_mknod()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux