NFSv4 Linux client atime for exclusive create
dfr at rabson.org
Wed Apr 19 15:06:55 UTC 2017
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 22.214.171.124 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
> 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
> --> 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
> Anyone have other ideas w.r.t. how to fix this?
> Does restricting NFSv4 exports to file systems that support extended
> attributes sound
> Thanks for any comments w.r.t. this, rick
> freebsd-fs at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
More information about the freebsd-fs