Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 2017 09:39:50 +0100
From:      Doug Rabson <dfr@rabson.org>
To:        Rick Macklem <rmacklem@uoguelph.ca>
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:  <CACA0VUjVg6BZc4SarH6UVn1DBrJc7MdfLkmKcbgq0OR1ExwD7Q@mail.gmail.com>
In-Reply-To: <YTXPR01MB0189EF41F4122B0162A76F0DDD180@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> <YTXPR01MB0189EF41F4122B0162A76F0DDD180@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
That was actually going to me my next suggestion, honest. Hopefully that
fixes the problem, if not its a bug in the Linux client.

On 19 April 2017 at 22:26, Rick Macklem <rmacklem@uoguelph.ca> wrote:

> 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@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
> 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@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?CACA0VUjVg6BZc4SarH6UVn1DBrJc7MdfLkmKcbgq0OR1ExwD7Q>