RFC: new NFS mount option or restore old behaviour for Solaris server bug?

[Rick Macklem]

Konstantin Belousov wrote:
> On Sat, Dec 27, 2014 at 09:28:16AM -0500, Rick Macklem wrote:
> > Hi,
> > 
> > The FreeBSD9.1 and earlier NFS clients almost always (unless the
> > tod clock ticked to next second while the operation was in
> > progress)
> > set the mtime to the server's time (xx_TOSERVER) for exclusive
> > open.
> > Starting with FreeBSD9.2, the mtime would be set to the client's
> > time
> > due to r245508, which fixed the code for utimes() to use
> > VA_UTIMES_NULL.
> > 
> > This change tickled a bug in recent Solaris servers, which return
> > NFS_OK to the Setattr RPC but don't actually set the file's mode
> > bits.
> > (The bug isn't tickled when mtime is set to the server's time.)
> > I have patches to work around this in two ways:
> > 1 - Add a new "useservertime" mount option that forces xx_TOSERVER.
> >     (This patch would force xx_TOSERVER for exclusive open.)
> >     It permits the man page to document why it is needed-->broken
> >     Solaris servers.
> > 2 - Use xx_TOSERVER for exclusive open always. Since this was the
> > normal
> >     behaviour until FreeBSD9.2, I don't think this would cause
> >     problems or
> >     be a POLA violation, but I can't be sure?
> > 
> > I am leaning towards #2, since it avoids yet another mount option.
> > However, I'd like other people's opinions on which option is
> > better,
> > or any other suggestions?
> I still do not quite understand the reasoning.
> 
> What are drawbacks of using #2, comparing with #1 ?  #1 requires
> manual
> configuration, and worse, it is not known which Solaris NFS servers
> require workaround, so arguments against #1 and for #2 are clean.
> But what are arguments against #2, if any ?
> 
The only risk with #2 that I can think of is that some post-FreeBSD9.1
change to the system breaks when the xx_TOSERVER is done, due to clock
skew. (There was recently a separate email thread on the resolution of
vfs_timestamp(), but with the default 1sec resolution, it doesn't seem
likely to me that this will happen.)

I originally proposed #1 because I didn't realize the behaviour had been
xx_TOSERVER prior to FreeBSD9.2 and thought it was just a broken Solaris
server.

Thanks for the comments. It looks like #2 is preferred unless someone
comes up with a good reason for #1 over it.

rick

> At least for me, #2 looks obviously better.
> > 
> > Thanks in advance for your comments, rick
> > ps: The trivial patch for #2 is attached, in case you are
> > interested.
> 
> > --- fs/nfsclient/nfs_clport.c.sav	2014-12-25 12:54:25.000000000
> > -0500
> > +++ fs/nfsclient/nfs_clport.c	2014-12-25 12:55:49.000000000 -0500
> > @@ -1096,9 +1096,16 @@ nfscl_checksattr(struct vattr *vap, stru
> >  	 * us to do a SETATTR RPC. FreeBSD servers store the verifier
> >  	 * in atime, but we can't really assume that all servers will
> >  	 * so we ensure that our SETATTR sets both atime and mtime.
> > +	 * Set the VA_UTIMES_NULL flag for this case, so that
> > +	 * the server's time will be used.  This is needed to
> > +	 * work around a bug in some Solaris servers, where
> > +	 * setting the time TOCLIENT causes the Setattr RPC
> > +	 * to return NFS_OK, but not set va_mode.
> >  	 */
> > -	if (vap->va_mtime.tv_sec == VNOVAL)
> > +	if (vap->va_mtime.tv_sec == VNOVAL) {
> >  		vfs_timestamp(&vap->va_mtime);
> > +		vap->va_vaflags |= VA_UTIMES_NULL;
> > +	}
> >  	if (vap->va_atime.tv_sec == VNOVAL)
> >  		vap->va_atime = vap->va_mtime;
> >  	return (1);
> 
>