On Wed, Apr 02, 2008 at 08:42:09PM -0400, Trond Myklebust wrote: > > At the very least, you want "that thing is still busy" on normal umount - > > we are still in the middle of write(2) and hell knows how long it's going > > to last. So you need to play with refcount of vfsmount in a very nasty > > way, for all your pains. > > We already call fget_light()/fput_light() around the whole call to > vfs_write(). Substituting a call to something which takes a reference to > the new structure is trivial. Huh? So you want an extra layer of indirection? descriptor table -> that one -> struct file? And refcounting these puppies? > It allows you to get rid of the vfsmount 'argument' when opening a file, > which again lowers the barrier for stacking filesystems. I don't see how that would fix the fundamental breakage in those, but anyway... (and yes, ecryptfs has interesting issues, but the look of it). > 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 really doubt that it's worth doing in this area... "Don't use ->f_vfsmnt in fs code" is easily enforced and struct file is really used outside of filesystem code in fs-independent ways. IOW, I don't believe that it's worth introducing a new layer between descriptor table and files. BTW, that'll complicate union-mount handling (real ones, not unionfs under different name) and quite a few other things... -- 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
