All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Barnes <qbarnes+nfs@yahoo-inc.com>
To: linux-nfs@vger.kernel.org
Subject: nfs_file_flush() question
Date: Sat, 16 Aug 2008 19:23:42 -0500	[thread overview]
Message-ID: <20080817002342.GA17223@yahoo-inc.com> (raw)

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?

Quentin

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

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-17  0:23 Quentin Barnes [this message]
2008-08-17 17:04 ` nfs_file_flush() question Trond Myklebust
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=20080817002342.GA17223@yahoo-inc.com \
    --to=qbarnes+nfs@yahoo-inc.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.