Re: NFSv4: cinfo->atomic and file creation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2017-06-09 at 14:04 -0400, Chuck Lever wrote:
> Hi Trond-
> 
> As we discussed yesterday, I'm concerned about the test in
> _nfs4_proc_open that uses the values of the cinfo.before and
> cinfo.after fields without checking cinfo.atomic.
> 
> 2288         if (o_arg->open_flags & O_CREAT) {
> 2289                 if (o_arg->open_flags & O_EXCL)
> 2290                         data->file_created = 1;
> 2291                 else if (o_res->cinfo.before != o_res-
> >cinfo.after)
> 2292                         data->file_created = 1;
> 2293                 if (data->file_created || dir->i_version !=
> o_res->cinfo.after)
> 2294                         update_changeattr(dir, &o_res->cinfo,
> 2295                                         o_res->f_attr-
> >time_start);
> 2296         }
> 
> Line 2291 is the issue.
> 
> Suppose the server filesystem substitutes a weak ctime for
> the change attribute. Sometimes when a file is successfully
> created on the server, the ctime of the parent doesn't
> change. This test then fails and leaves file_created set
> to zero.

A server which uses a ctime with insufficient resolution is in
violation of the requirements for a change attribute. The spec
explicitly disallows it in https://tools.ietf.org/html/rfc5661#section-
5.8.1.4

IOW: the remainder of the spec (including the definition of OPEN) does
expect that you can rely on the change attribute for detecting file
changes.

> Later, nfs4_opendata_access looks at file_created. If not
> set, the access check fails and open(2) returns EACCES as
> a result, even though the file was created successfully
> and OPEN returned NFS4_OK.
> 
> You mentioned that the server should set cinfo.atomic to
> be false when a weak ctime is used as the change attribute.
> Will that help in this case?

No. The cinfo.atomic flag is there to let you know that the change you
are seeing in the directory was caused by the operation that just
executed. If it is set to "false" then that does not really tell you
much about whether or not you can trust that a change occurred.

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux