Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Apr 2017 22:44:53 +0000
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Cc:        "jim@ks.uiuc.edu" <jim@ks.uiuc.edu>
Subject:   NFSv4 Linux client atime for exclusive create
Message-ID:  <YTXPR01MB018992D6CDD2A578B4AC946BDD050@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>

next in thread | raw e-mail | index | archive | help
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 i=
s
happening, but it turns out to be interesting and I am not sure I have a go=
od 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 w=
ith 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 met=
adata, which is not
           what atime is supposed to do. (Yuck!)
2 - For NFSv4, store the create_verifier in an extended attribute instead o=
f 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 cl=
ients.

Anyone have other ideas w.r.t. how to fix this?

Does restricting NFSv4 exports to file systems that support extended attrib=
utes sound
reasonable?

Thanks for any comments w.r.t. this, rick=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB018992D6CDD2A578B4AC946BDD050>