NFSv4 Linux client atime for exclusive create

[Rick Macklem]

Hope you don't mind a quick top post related to my last email...
I just looked in the new RFC for NFSv4.0 and it notes that the reply
to Open should specify the attribute(s) used to store the create_verifier.
Either this wasn't in the original RFC (3530) or I never read it, because the
FreeBSD NFSv4.0 server doesn't do this.

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 behaviour.

Also, the server doesn't set this bit in the EXCLUSIVE4_1 reply as RFC5661
says it should, so I need to patch this too.

I suspect this will fix the problem without using an extended attribute to
store the create_verifier.

Having said that, I think that storing the create_verifier in an extended attribute
might be a good idea, for file systems that support them?

Thanks for the comments that convinced me to take another look at the RFCs, rick
________________________________________
From: owner-freebsd-fs at freebsd.org <owner-freebsd-fs at freebsd.org> on behalf of Rick Macklem <rmacklem at uoguelph.ca>
Sent: Wednesday, April 19, 2017 4:29:08 PM
To: Doug Rabson
Cc: freebsd-fs at freebsd.org; jim at ks.uiuc.edu
Subject: Re: NFSv4 Linux client atime for exclusive create

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 >force the client to update it separately.
The packet trace Jim sent me was NFSv4.0 and, as such, used EXCLUSIVE4.
(The Open was followed by a Setattr in a separate compound RPC that only specified
 the "mode" attribute. The client never seemed to specify an atime.)

I haven't tried an NFSv4.1 mount yet, but I need to take a look at it.
(I did succeed in reproducing the problem with an NFSV4.0 mount from a Linux
 box I have.)

>It would be helpful to see a packet trace for this which should make it clearer what is >happening here.
Jim did send me this off list.

I now have a patch that stores the create_verifier in an extended attribute and I think
that should be fine? (It does imply that NFSv4.0 read/write mounts will only work
correctly for server file systems that support extended attributes, but I think that
is a reasonable restriction that can't be avoided?)
[stuff snipped]

rick
_______________________________________________
freebsd-fs at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"