NFSv4 Linux client atime for exclusive create

[Doug Rabson]

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.

It would be helpful to see a packet trace for this which should make it
clearer what is happening here.


On 14 April 2017 at 23:44, Rick Macklem <rmacklem at uoguelph.ca> wrote:

> PR#218218 reports a problem where a file created by an NFSv4 mount (using
> a recent
> Linux kernel) results in a bogus atime for the newly created file.
>
> With the help of a packet trace from the problem reported I now know what
> is
> happening, but it turns out to be interesting and I am not sure I have a
> good way
> to fix it.
> Here's the story...
> - The Linux client does an Exclusive create.
> - As was the norm for NFSv3, the FreeBSD server stores the create_verifier
> for this
>   exclusive create in the atime field of the newly created file, so it can
> be checked
>   for a retry of the exclusive create.
>   --> For NFSv3, it was required that a client follow an exclusive create
> with a Setattr
>         of atime to fix the atime.
> It turns out that, for NFSv4, the client is not required to do the Setattr
> of atime.
> (The FreeBSD client does do this and I think older Linux NFSv4 clients
> did.)
> --> This Linux client follows the exclusive create with a Setattr, but
> only for the "mode"
>      attribute, leaving the create_verifier in the atime field.
>
> I can think of two ways to fix this:
> 1 - Make the Setattr set atime whenever it sets any other attribute.
>      --> This would result in atime being set for changes to the file's
> metadata, which is not
>            what atime is supposed to do. (Yuck!)
> 2 - For NFSv4, store the create_verifier in an extended attribute instead
> of atime.
>      --> I think this would work, but it would imply that only file
> systems that support
>            extended attributes (UFS, ZFS, ??) could be exported to NFSv4
> clients.
>
> Anyone have other ideas w.r.t. how to fix this?
>
> Does restricting NFSv4 exports to file systems that support extended
> attributes sound
> reasonable?
>
> Thanks for any comments w.r.t. this, 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"
>