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




[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