From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@redhat.com>,
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 14:16:28 -0400 [thread overview]
Message-ID: <1269540988.3648.46.camel@localhost.localdomain> (raw)
In-Reply-To: <20100325174707.GA4033@fieldses.org>
On Thu, 2010-03-25 at 13:47 -0400, J. Bruce Fields wrote:
> 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.
We're certainly expected to write back data before returning a write
delegation (see Section 9.4.4 of RFC 3530).
For the case of a read delegation, then the spec is silent because it
contains no discussion of the case where a server grants both an open
for write and a read delegation. If you want a normative statement on
what clients should do for that case, then I suggest a discussion on the
IETF list with a view to getting it into RFC3530-bis.
Trond
next prev parent reply other threads:[~2010-03-25 18:16 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
2010-03-25 18:16 ` Trond Myklebust [this message]
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=1269540988.3648.46.camel@localhost.localdomain \
--to=trond.myklebust@fys.uio.no \
--cc=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 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.