From owner-freebsd-fs@freebsd.org Fri Apr 21 16:39:34 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EF57D48107 for ; Fri, 21 Apr 2017 16:39:34 +0000 (UTC) (envelope-from jim@ks.uiuc.edu) Received: from halifax.ks.uiuc.edu (halifax.ks.uiuc.edu [130.126.120.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailhost.ks.uiuc.edu", Issuer "Thawte Premium Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D03D614CF for ; Fri, 21 Apr 2017 16:39:33 +0000 (UTC) (envelope-from jim@ks.uiuc.edu) Received: from sunnyvale.ks.uiuc.edu (sunnyvale.ks.uiuc.edu [130.126.120.168]) by halifax.ks.uiuc.edu (8.13.7/8.13.7) with ESMTP id v3LGPNje003148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Apr 2017 11:25:24 -0500 (CDT) Received: from localhost (jim@localhost) by sunnyvale.ks.uiuc.edu (8.14.4/8.14.4/Submit) with ESMTP id v3LGPNIw098654; Fri, 21 Apr 2017 11:25:23 -0500 X-Authentication-Warning: sunnyvale.ks.uiuc.edu: jim owned process doing -bs Date: Fri, 21 Apr 2017 11:25:23 -0500 (CDT) From: Jim Phillips To: Rick Macklem cc: Doug Rabson , "freebsd-fs@freebsd.org" Subject: Re: NFSv4 Linux client atime for exclusive create In-Reply-To: Message-ID: References: , MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:39:34 -0000 Tested the new patch and it fixes the issue (as did the old one). Jim On Thu, 20 Apr 2017, Rick Macklem wrote: > Doug Rabson wrote: >> That was actually going to me my next suggestion, honest. Hopefully that fixes the >problem, if not its a bug in the Linux client. > Yep, the attached patch fixed the problem. > > I wrote: >> I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open >> reply and see if that changes the Linux client. > The attached patch sets the TIMEACCESS bit in the reply for both NFSv4.0 and NFSv4.1 > and fixes the problem for both cases for a quick test with the Linux client. (With this > bit set in the reply, Linux sets TIMEACCESSSET in the Setattr.) > > Doug Rabson wrote: >> Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUSIVE4_1, i.e. the >mode which allows attribute setting during the open, the client should use the value of >the supattr_exclcreat attribute (see section 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this case, supattr_exclcreat should not include atime which should > The FreeBSD NFSv4.1 server does exclude atime from the supattr_exclcreat bitset and > it checks for it set and returns the correct error. > However, like NFSv4.0, the code didn't set the TIMEACCESS attribute bit in the > EXCLUSIVE4_1 reply. (The attached little patch fixes this for both NFSv4.0 and NFSV4.1.) > > Thanks everyone for your help. > > I am thinking that storing the create_verifier in an extended attribute for file > systems that support extended attributes is a good idea, since it will allow NFSv4.1 > clients to avoid following the Open/Exclusive4_1 with a Setattr RPC. > Anyone else have an opinion w.r.t. this? > (I'll leave this for a future commit, depending on what others think of the idea.) > > I will probably commit the attached patch soon, rick > ps: Jim, I don't think there is any point in testing the other patch, although I suspect > it would fix the problem. You could test this one, if you can easily do it. > pss: My only excuse for never doing this is that it is one sentence in an RFC of > several hundred pages;-) >