[topic proposal] dealing with ->d_revalidate() right ways (automounting, atomic opens and the whole mess around that)

[topic proposal] dealing with ->d_revalidate() right ways (automounting, atomic opens and the whole mess around that)

[Al Viro]

	That's going to be the next big change of VFS architecture; bits
and pieces had been discussed on lists and in private mail, but it would
be really useful to sit down and discuss that face to face with everyone
involved.

	* ->follow_link() is abused for triggering submounts.
	* ->d_revalidate() is abused in many, _many_ ways, including
autofs, NFS "reval_dot" stuff, atomic opens, etc.  Moreover, it has nasty
interplay with crossing mountpoints.
	* NFS handling of atomic opens is near the point where we can
switch to methods that would get proper arguments directly, rather
than abusing ->lookup/->d_revalidate/whatnot.  Again, ->d_revalidate
and mountpoint crossing are stumbling blocks.  And NFS4 bits around
open are just plain scary...
	* NFSv4 has rather unpleasant stuff in submount handling - what
it does with ->mnt_devname doesn't bear describing in polite company and
it actually doesn't work right with mount --bind (moderately) and
mountinfo contents (completely).  Both issues are fixable and that gets
entangled into the aforementioned ball of barbed wire...

	Who might want to be there: nfsd/nfs/cifs/afs/autofs4 and general
VFS-interested folks.

Re: [topic proposal] dealing with ->d_revalidate() right ways (automounting, atomic opens and the whole mess around that)

[Joel Becker]

On Wed, Jun 09, 2010 at 03:19:40AM +0100, Al Viro wrote:
> 	That's going to be the next big change of VFS architecture; bits
> and pieces had been discussed on lists and in private mail, but it would
> be really useful to sit down and discuss that face to face with everyone
> involved.

	I'd want to be in on this from the ocfs2 perspective.  I think
that d_revalidate() works for us as-is, but I'd want to be in on
proposed changes.

Joel

-- 

"We'd better get back, `cause it'll be dark soon,
 and they mostly come at night.  Mostly."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [topic proposal] dealing with ->d_revalidate() right ways (automounting, atomic opens and the whole mess around that)

[Trond Myklebust]

On Wed, 2010-06-09 at 03:19 +0100, Al Viro wrote:
> 	That's going to be the next big change of VFS architecture; bits
> and pieces had been discussed on lists and in private mail, but it would
> be really useful to sit down and discuss that face to face with everyone
> involved.
> 
> 	* ->follow_link() is abused for triggering submounts.
> 	* ->d_revalidate() is abused in many, _many_ ways, including
> autofs, NFS "reval_dot" stuff, atomic opens, etc.  Moreover, it has nasty
> interplay with crossing mountpoints.
> 	* NFS handling of atomic opens is near the point where we can
> switch to methods that would get proper arguments directly, rather
> than abusing ->lookup/->d_revalidate/whatnot.  Again, ->d_revalidate
> and mountpoint crossing are stumbling blocks.  And NFS4 bits around
> open are just plain scary...
> 	* NFSv4 has rather unpleasant stuff in submount handling - what
> it does with ->mnt_devname doesn't bear describing in polite company and
> it actually doesn't work right with mount --bind (moderately) and
> mountinfo contents (completely).  Both issues are fixable and that gets
> entangled into the aforementioned ball of barbed wire...
> 
> 	Who might want to be there: nfsd/nfs/cifs/afs/autofs4 and general
> VFS-interested folks.
> --

I second. It would be great to clean all this up and get rid of the
intents stuff. Al and I started the discussion last year, but it would
be useful to include a larger audience.

Cheers
  Trond

Re: [topic proposal] dealing with ->d_revalidate() right ways (automounting, atomic opens and the whole mess around that)

[Frank Mayhar]

On Wed, 2010-06-09 at 03:19 +0100, Al Viro wrote:
> 	That's going to be the next big change of VFS architecture; bits
> and pieces had been discussed on lists and in private mail, but it would
> be really useful to sit down and discuss that face to face with everyone
> involved.

Sorry to come in late; I've been on vacation.  Are you proposing that
this happen at the summit in August?  Or at some other time?
-- 
Frank Mayhar <fmayhar@google.com>
Google, Inc.