Re: [PATCH] nfs(5): Clarify DATA AND METADATA COHERENCE section

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

 



On Jan 16, 2014, at 12:14 PM, Trond Myklebust <trondmy@xxxxxxxxx> wrote:

> 
> 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.

“noac” now has:

                      The DATA  AND  METADATA  COHERENCE  section  contains  a
                      detailed discussion of these trade-offs.

“lookupcache” has:

                      The DATA  AND  METADATA  COHERENCE  section  contains  a
                      detailed discussion of these trade-offs.

And “cto” has:

                      server changes only occasionally.  The DATA AND METADATA
                      COHERENCE section discusses the behavior of this  option
                      in more detail.

We can add this to ac{reg,dir}{min,max}:

                      See the DATA AND METADATA COHERENCE section for  a  full
                      discussion of attribute caching.

Is that what you were thinking?

> 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
> 

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com



--
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




[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