NFSv4 Linux client atime for exclusive create

Rick Macklem rmacklem at uoguelph.ca
Thu Apr 20 23:46:03 UTC 2017


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;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atime2.patch
Type: application/octet-stream
Size: 476 bytes
Desc: atime2.patch
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20170420/300c1ff9/attachment.obj>


More information about the freebsd-fs mailing list