From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org,
Trond Myklebust <trond@netapp.com>
Subject: Re: [PATCH] nfsd: don't break lease while servicing a COMMIT call (try #2)
Date: Thu, 25 Mar 2010 13:47:08 -0400 [thread overview]
Message-ID: <20100325174707.GA4033@fieldses.org> (raw)
In-Reply-To: <20100322163340.4b3b285f@tlielax.poochiereds.net>
On Mon, Mar 22, 2010 at 04:33:40PM -0400, Jeff Layton wrote:
> It looks like nfs_inode_return_delegation always calls nfs_msync_inode
> on any valid delegation before returning it, regardless of the
> delegation type.
>
> RFC 3530 says this:
>
> If the client is granted a read delegation, it is assured that no
> other client has the ability to write to the file for the duration of
> the delegation. If the client is granted a write delegation, the
> client is assured that no other client has read or write access to
> the file.
>
> That doesn't seem to imply that we must flush writes before returning
> either type of delegation. OTOH, maybe it makes sense to treat those as
> cache consistency points since a delegreturn sort of implies that
> another client wants to use the file.
>
> I'm not quite sure how to interpret the spec here...
If there's that call could cause the client to wait for an actual write
to succeed before returning the delegation, then something's wrong.
Waiting for a commit also seems strange, but probably not incorrect: it
seems fair for the client to expect the server not to treat a commit as
conflicting with a delegation.
--b.
next prev parent reply other threads:[~2010-03-25 17:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-19 12:06 [PATCH] nfsd: don't break lease while servicing a COMMIT call (try #2) Jeff Layton
2010-03-22 19:47 ` J. Bruce Fields
2010-03-22 20:33 ` Jeff Layton
2010-03-25 17:47 ` J. Bruce Fields [this message]
2010-03-25 18:16 ` Trond Myklebust
2010-03-25 22:07 ` J. Bruce Fields
2010-03-26 14:45 ` Jeff Layton
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=20100325174707.GA4033@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=trond@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox