Date: Sun, 28 Dec 2014 07:49:38 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: RFC: new NFS mount option or restore old behaviour for Solaris server bug? Message-ID: <1766916330.3067344.1419770978659.JavaMail.root@uoguelph.ca> In-Reply-To: <20141228091947.GB98945@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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);
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1766916330.3067344.1419770978659.JavaMail.root>