NFSv4 Linux client atime for exclusive create

Rick Macklem rmacklem at uoguelph.ca
Fri Apr 14 22:44:56 UTC 2017


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


More information about the freebsd-fs mailing list