From owner-freebsd-fs@FreeBSD.ORG Sun Dec 28 12:49:40 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD48B75B; Sun, 28 Dec 2014 12:49:40 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 68B2E1C4F; Sun, 28 Dec 2014 12:49:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAG/7n1SDaFve/2dsb2JhbABchDSDAccHglACgSABAQEBAX2EDAEBAQMBIwRSBRYOCgICDRkCWQaINwivTJReAQEBAQEBAQMBAQEBAQEBG4EhiGyFBwERARw0B4JogUEFiUuOSo0KgzkihAwggT05fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,655,1413259200"; d="scan'208";a="181502771" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 28 Dec 2014 07:49:39 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A46C13CE1D; Sun, 28 Dec 2014 07:49:38 -0500 (EST) Date: Sun, 28 Dec 2014 07:49:38 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <1766916330.3067344.1419770978659.JavaMail.root@uoguelph.ca> In-Reply-To: <20141228091947.GB98945@kib.kiev.ua> Subject: Re: RFC: new NFS mount option or restore old behaviour for Solaris server bug? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 12:49:41 -0000 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); > >