Date: Wed, 19 Apr 2017 21:26:48 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Doug Rabson <dfr@rabson.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, "jim@ks.uiuc.edu" <jim@ks.uiuc.edu> Subject: Re: NFSv4 Linux client atime for exclusive create Message-ID: <YTXPR01MB0189EF41F4122B0162A76F0DDD180@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <YTXPR01MB0189374B9DCCB8D0219FA299DD180@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> References: <YTXPR01MB018992D6CDD2A578B4AC946BDD050@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>, <CACA0VUgkRphRLQh%2BFBcCEb=gB=YdjVFEncor64x1qqov7K4%2Bhw@mail.gmail.com>, <YTXPR01MB0189374B9DCCB8D0219FA299DD180@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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 t= he 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 a= ttribute 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@freebsd.org <owner-freebsd-fs@freebsd.org> on behalf= of Rick Macklem <rmacklem@uoguelph.ca> Sent: Wednesday, April 19, 2017 4:29:08 PM To: Doug Rabson Cc: freebsd-fs@freebsd.org; jim@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 EXCLUS= IVE4_1, i.e. the >mode which allows attribute setting during the open, the = client should use the value of >the supattr_exclcreat attribute (see sectio= n 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this c= ase, supattr_exclcreat should not include atime which should >force the cli= ent 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 sp= ecified 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 Linu= x box I have.) >It would be helpful to see a packet trace for this which should make it cl= earer 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 onl= y work correctly for server file systems that support extended attributes, but I t= hink that is a reasonable restriction that can't be avoided?) [stuff snipped] rick _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB0189EF41F4122B0162A76F0DDD180>