On Jan 16, 2014, at 12:09, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > --- > How about something like this? We really want something in the acregmin/max, acdirmin/max descriptions that refers to the cache coherency discussion too. Cheers, Trond > > utils/mount/nfs.man | 28 ++++++++++++++++++---------- > 1 file changed, 18 insertions(+), 10 deletions(-) > > diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man > index 2250963..99c9fc3 100644 > --- a/utils/mount/nfs.man > +++ b/utils/mount/nfs.man > @@ -1161,24 +1161,32 @@ perfect cache coherence among their clients. > Perfect cache coherence among disparate NFS clients > is expensive to achieve, especially on wide area networks. > As such, NFS settles for weaker cache coherence that > -satisfies the requirements of most file sharing types. Normally, > -file sharing is completely sequential: > -first client A opens a file, writes something to it, then closes it; > -then client B opens the same file, and reads the changes. > -.DT > +satisfies the requirements of most file sharing types. > .SS "Close-to-open cache consistency" > -When an application opens a file stored on an NFS server, > -the NFS client checks that it still exists on the server > +Typically file sharing is completely sequential. > +First client A opens a file, writes something to it, then closes it. > +Then client B opens the same file, and reads the changes. > +.P > +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 > +independent of the freshness of the file's attribute cache. > +.P > When the application closes the file, > the NFS client writes back any pending changes > to the file so that the next opener can view the changes. > This also gives the NFS client an opportunity to report > -any server write errors to the application > -via the return code from > +write errors to the application via the return code from > .BR close (2). > +.P > The behavior of checking at open time and flushing at close time > -is referred to as close-to-open cache consistency. > +is referred to as > +.IR "close-to-open cache consistency" , > +or CTO. > +It can be disabled for an entire mount point using the > +.B nocto > +mount option. > .SS "Weak cache consistency" > There are still opportunities for a client's data cache > to contain stale data. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
