NFSv4 Linux client atime for exclusive create

Rick Macklem rmacklem at uoguelph.ca
Fri Apr 21 19:51:43 UTC 2017


Ok. Thanks for testing it. It is committed to head and will be MFC'd in
a couple of weeks.

Sorry it was broken for sooooo looonnnggg, rick
________________________________________
From: Jim Phillips <jim at ks.uiuc.edu>
Sent: Friday, April 21, 2017 12:25:23 PM
To: Rick Macklem
Cc: Doug Rabson; freebsd-fs at freebsd.org
Subject: Re: NFSv4 Linux client atime for exclusive create

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;-)
>


More information about the freebsd-fs mailing list