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
next prev parent 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