All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, trond.myklebust@netapp.com
Subject: Re: [PATCH] nfs(5): Treatment of *atime mount options
Date: Wed, 20 Nov 2013 16:25:10 -0500	[thread overview]
Message-ID: <528D28B6.7060009@RedHat.com> (raw)
In-Reply-To: <20131118153645.912.68903.stgit@seurat.1015granger.net>



On 18/11/13 10:36, Chuck Lever wrote:
> I was reminded recently that NFS treats file atime time stamps
> differently than other filesystems.  It also ignores the generic
> *atime mount options because it cannot support the atime semantics
> of local filesystems.
> 
> We should document that somewhere.  nfs(5) seems like a logical
> place for it.
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Committed (tag: nfs-utils-1-2-10-rc1)

steved.

> ---
>  utils/mount/nfs.man |   59 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index 67031b5..2250963 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1227,6 +1227,65 @@ If absolute cache coherence among clients is required,
>  applications should use file locking. Alternatively, applications
>  can also open their files with the O_DIRECT flag
>  to disable data caching entirely.
> +.SS "File timestamp maintainence"
> +NFS servers are responsible for managing file and directory timestamps
> +.RB ( atime ,
> +.BR ctime ", and"
> +.BR mtime ).
> +When a file is accessed or updated on an NFS server,
> +the file's timestamps are updated just like they would be on a filesystem
> +local to an application.
> +.P
> +NFS clients cache file attributes, including timestamps.
> +A file's timestamps are updated on NFS clients when its attributes
> +are retrieved from the NFS server.
> +Thus there may be some delay before timestamp updates
> +on an NFS server appear to applications on NFS clients.
> +.P
> +To comply with the POSIX filesystem standard, the Linux NFS client
> +relies on NFS servers to keep a file's
> +.B mtime
> +and
> +.B ctime
> +timestamps properly up to date.
> +It does this by flushing local data changes to the server
> +before reporting
> +.B mtime
> +to applications via system calls such as
> +.BR stat (2).
> +.P
> +The Linux client handles
> +.B atime
> +updates more loosely, however.
> +NFS clients maintain good performance by caching data,
> +but that means that application reads, which normally update
> +.BR atime ,
> +are not reflected to the server where a file's
> +.B atime
> +is actually maintained.
> +.P
> +Because of this caching behavior,
> +the Linux NFS client does not support generic atime-related mount options.
> +See
> +.BR mount (8)
> +for details on these options.
> +.P
> +In particular, the
> +.BR atime / noatime ,
> +.BR diratime / nodiratime ,
> +.BR relatime / norelatime ,
> +and
> +.BR strictatime / nostrictatime
> +mount options have no effect on NFS mounts.
> +.P
> +.I /proc/mounts
> +may report that the
> +.B relatime
> +mount option is set on NFS mounts, but in fact the
> +.B atime
> +semantics are always as described here, and are not like
> +.B relatime
> +semantics.
>  .SS "Directory entry caching"
>  The Linux NFS client caches the result of all NFS LOOKUP requests.
>  If the requested directory entry exists on the server,
> 

      reply	other threads:[~2013-11-20 21:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 15:36 [PATCH] nfs(5): Treatment of *atime mount options Chuck Lever
2013-11-20 21:25 ` Steve Dickson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528D28B6.7060009@RedHat.com \
    --to=steved@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@netapp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.