From: Jim Rees <rees@umich.edu>
To: Jeff Layton <jlayton@redhat.com>
Cc: andros@netapp.com, trond.myklebust@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/4] RFC Avoid expired credential keys for buffered writes
Date: Mon, 10 Sep 2012 15:56:50 -0400 [thread overview]
Message-ID: <20120910195650.GA3095@umich.edu> (raw)
In-Reply-To: <20120910145732.4d800f5b@corrin.poochiereds.net>
Jeff Layton wrote:
My only concern is this behavior described in the last patch:
"If the buffered WRITE is using a credential key that will expire
within low watermark seconds, fail the WRITE in nfs_write_begin
_before_ the WRITE is buffered and return -EACCES to the application."
Shouldn't rejecting the write attempt be the purview of the server?
It seems to me that we'd be best off just switching to synchronous
writes when we start approaching credential expiration, and letting the
server handle the case where the credential expires.
It seems to me that the client should just be in the business of
recognizing when the credential might be about to expire and attempt to
ensure that we don't end up with a bunch of buffered data in that case.
I don't like it. It's easy to understand why writes might fail if the creds
are getting stale. It's not so easy to understand why client behavior
changes in a subtle way, with performance implications.
next prev parent reply other threads:[~2012-09-10 19:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-06 19:54 [PATCH 0/4] RFC Avoid expired credential keys for buffered writes andros
2012-09-06 19:54 ` [PATCH 1/4] SUNRPC handle EKEYEXPIRED in call_refreshresult andros
2012-09-06 19:54 ` [PATCH 2/4] SUNRPC set gss gc_expiry to full lifetime andros
2012-09-06 19:54 ` [PATCH 3/4] SUNRPC new rpc_credops to test credential expiry andros
2012-09-06 19:54 ` [PATCH 4/4] NFS avoid expired credential keys for buffered writes andros
2012-09-07 1:36 ` [PATCH 0/4] RFC Avoid " Jim Rees
2012-09-10 18:57 ` Jeff Layton
2012-09-10 19:52 ` Adamson, Andy
2012-09-10 20:08 ` Jeff Layton
2012-09-12 15:13 ` Adamson, Andy
2012-09-12 15:21 ` Myklebust, Trond
2012-09-12 16:14 ` Adamson, Andy
2012-09-13 17:57 ` J. Bruce Fields
2012-09-13 18:09 ` Myklebust, Trond
2012-09-13 18:21 ` J. Bruce Fields
2012-09-13 18:12 ` Adamson, Andy
2012-09-10 20:12 ` Myklebust, Trond
2012-09-10 19:56 ` Jim Rees [this message]
2012-09-10 20:14 ` Myklebust, Trond
2012-09-10 21:03 ` Adamson, Andy
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=20120910195650.GA3095@umich.edu \
--to=rees@umich.edu \
--cc=andros@netapp.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@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;
as well as URLs for NNTP newsgroup(s).