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