From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org, Olga Kornievskaia <aglo@citi.umich.edu>
Subject: Re: [PATCH 2/6] rpc: timeout patch
Date: Mon, 9 Jun 2008 17:39:12 -0400 [thread overview]
Message-ID: <20080609213912.GC32446@fieldses.org> (raw)
In-Reply-To: <1213046330.19130.12.camel@localhost>
On Mon, Jun 09, 2008 at 05:18:50PM -0400, Trond Myklebust wrote:
> On Mon, 2008-06-09 at 16:51 -0400, J. Bruce Fields wrote:
> > From: Olga Kornievskaia <aglo@citi.umich.edu>
> >
> > When a client gss upcall times out, we currently give a mesage reminding
> > the user to check whether gssd is running.
> >
> > Currently gssd only listens on pipes under nfs/. We expect to modify it
> > so it treats all clients the same regardless of protocol (as it probably
> > should have before), and new functionality may depend on that. So
> > people may need to upgrade gssd to get such new functionality.
> >
> > So it would be helpful if the error message specified which pipe exactly
> > the upcall was failing on, and suggested that the problem could be due
> > to an outdated gssd (not just a non-existant gssd).
>
> NACK. I belive I've already made clear that I really don't like the idea
> of using d_path() in an error message.
>
> Please just correct the existing error message to remind people that
> they need an up to date version of gssd, and add a comment in Kconfig
> stating exactly _which_ minimal version is needed.
Actually, after another look, maybe we should just do nothing:
The most likely next user of this is the nfsv4 callbacks. But callbacks
aren't that crucial: if someone doesn't care about delegations, and
wants to delay upgrading gssd, they should be able to do that without
their server's logs getting spammed all the time.
So I'm inclined to just drop this--apologies.
--b.
prev parent reply other threads:[~2008-06-09 21:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 20:51 miscellaneous nfs patches for 2.6.27 J. Bruce Fields
2008-06-09 20:51 ` [PATCH 1/6] rpc: bring back cl_chatty J. Bruce Fields
2008-06-09 20:51 ` [PATCH 2/6] rpc: timeout patch J. Bruce Fields
2008-06-09 20:51 ` [PATCH 3/6] rpc: eliminate unused variable in auth_gss upcall code J. Bruce Fields
2008-06-09 20:51 ` [PATCH 4/6] rpc: remove some unused macros J. Bruce Fields
2008-06-09 20:51 ` [PATCH 5/6] rpc: minor cleanup of scheduler callback code J. Bruce Fields
2008-06-09 20:51 ` [PATCH 6/6] nfs: Fix misparsing of nfsv4 fs_locations attribute J. Bruce Fields
2008-06-09 21:08 ` Trond Myklebust
2008-06-09 21:22 ` J. Bruce Fields
2008-06-10 15:34 ` Chuck Lever
2008-06-10 19:17 ` J. Bruce Fields
2008-06-10 20:51 ` Chuck Lever
2008-06-11 17:59 ` J. Bruce Fields
2008-06-09 21:10 ` Chuck Lever
2008-06-09 21:18 ` [PATCH 2/6] rpc: timeout patch Trond Myklebust
2008-06-09 21:39 ` J. Bruce Fields [this message]
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=20080609213912.GC32446@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=aglo@citi.umich.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox