Re: [PATCH] nfs(5): Update close-to-open discussion in DATA AND METADATA COHERENCY

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Mar 05, 2015 at 03:18:00PM -0500, Trond Myklebust wrote:
> On Thu, Mar 5, 2015 at 1:42 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Thu, Mar 05, 2015 at 11:06:37AM -0500, Chuck Lever wrote:
> >> The discussion of close-to-open describes the GETATTR and data flush
> >> behavior implemented on the Linux client, but does not describe what
> >> happens between open() and close(). The lack of strict cache
> >> coherency surprises users who expect single-system behavior
> >> similar to local file systems.
> >>
> >> An explicit description of this behavior is inserted.  Additional
> >> clarifications are made of the surrounding text.
> >>
> >> Text contributed by Trond, Bruce, Chuck, and Chris Perl.
> >>
> >> Link: http://marc.info/?l=linux-nfs&m=142472673425307&w=2
> >> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >> ---
> >> Hi-
> >>
> >> TBH I'm more concerned about nfs(5) than I am about the antique NFS
> >> FAQ. Besides, my sf.net login expired long ago, after I retired from
> >> FAQ maintenance.
> >
> > If someone wanted to just copy the whole thing over to the linux-nfs.org
> > wiki, I'd support that.
> >
> >> Thus I'm proposing this change to nfs(5). Then I'd like to suggest
> >> eventually replacing the bulk of FAQ A8 with a pointer to the DATA
> >> AND METADATA COHERENCE section of nfs(5).
> >
> > Moving it to the man pages sounds fine to me too, though.
> >
> >> Comments?
> >
> > We're leading with the mechanism (flushing and attribute checking),
> > which I think encourages people to reason starting from the
> > implementation.  We know that's difficult.
> >
> > I'd rather lead with a conservative black-box explanation of what
> > applications can and cannot depend on.
> >
> 
> This should be the case here.  Exactly what are we saying that you
> believe goes beyond the close-to-open caching model?

Nothing.  I'm not claiming the text is incorrect.  I would just prefer
that we begin by describing the behavior from the point of view of a
user of the filesystem interface, rather than from the point of view of
the implementation.

Statements like

	When an application opens a file stored on an NFS version 3
	server, the NFS client checks that the file exists on the server
	and is permitted to the opener by sending a GETATTR or ACCESS
	request.  The NFS client sends these requests regardless of the
	freshness of the file's cached attributes.

describe the implementation.

A block-box explanation of what applications can and cannot depend on
might consist of statements of the form:

	Access from multiple processes on the same client provides the
	same guarantees as on local filesystems.

	Access from multiple clients will provide the same guarantees as
	long as no client's open for write overlaps any other open from
	another client.

	If a client does open a file for read while another holds it
	open for write, results of that client's reads are undefined.

Etc.

--b.