Linux NFS development
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Quentin Barnes <qbarnes+nfs@yahoo-inc.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: nfs_file_flush() question
Date: Sun, 17 Aug 2008 13:04:01 -0400	[thread overview]
Message-ID: <1218992641.7999.2.camel@localhost> (raw)
In-Reply-To: <20080817002342.GA17223@yahoo-inc.com>

On Sat, 2008-08-16 at 19:23 -0500, Quentin Barnes wrote:
> I've been coming up to speed on the NFS protocol and its NFS client
> support in Linux.  I've been comparing performance of NFS on RHEL4
> and RHEL5 vs. FreeBSD 6.2.  (Okay, we're on an old base, but I don't
> think it matters here for this question.)
> 
> In watching the NFS protocols fly back and forth between BSD
> and Linux clients to an NFS server, I noticed that Linux is
> doing an extra GETATTR over FreeBSD when closing a read-write
> file.  I tracked this back to nfs_file_flush() which is
> doing a __nfs_revalidate_inode() (or in current kernels
> nfs_revalidate_inode()).  Why do we want nfs_file_flush() to force
> a revalidate of an inode we're closing?  Why not instead just
> invalidate the inode's attribute?
> 
> I looked at the FreeBSD 6.2 code.  In its nfs_close(), it does an
> "np->n_attrstamp = 0;" to invalidate the inode's attribute cache.
> 
> The current Linux kernel code in question in nfs_file_flush() is:
> ==========
>     /* Ensure that data+attribute caches are up to date after close() */
>     status = nfs_do_fsync(ctx, inode);
>     if (!status)
>             nfs_revalidate_inode(NFS_SERVER(inode), inode);
> ==========
> 
> I would imagine this better as:
> ==========
>     /* Ensure that data+attribute caches are up to date after close() */
>     status = nfs_do_fsync(ctx, inode);
>     if (!status && !(NFS_SERVER(inode)->flags & NFS_MOUNT_NOCTO))
>             NFS_I(inode)->cache_validity |= NFS_INO_INVALID_ATTR;
> ==========
> 
> Is there a reason I'm missing that the revalidate and GETATTR are
> required?

Yes: It is required for correct close-to-open cache consistency
semantics.

If I don't know the correct mtime attribute of the file when I close it,
then I can't compare it with the mtime of the file when I open it again.
If so, close-to-open semantics forbid me from assuming that my cached
data is still valid, and so I have to throw out the entire page cache
contents for that file.

Cheers
  Trond


  reply	other threads:[~2008-08-17 17:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-17  0:23 nfs_file_flush() question Quentin Barnes
2008-08-17 17:04 ` Trond Myklebust [this message]
2008-08-18 16:04   ` Chuck Lever
2008-08-18 16:53     ` Trond Myklebust
2008-08-19 20:17   ` Quentin Barnes
2008-08-20  0:30     ` Trond Myklebust
2008-08-20  3:38       ` Quentin Barnes

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=1218992641.7999.2.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-nfs@vger.kernel.org \
    --cc=qbarnes+nfs@yahoo-inc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox