From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 10/11] NFSv4.1: Enable open-by-filehandle
Date: Tue, 19 Mar 2013 11:23:05 -0400 [thread overview]
Message-ID: <20130319152304.GG7912@fieldses.org> (raw)
In-Reply-To: <1363706205.7515.43.camel@leira.trondhjem.org>
On Tue, Mar 19, 2013 at 03:16:46PM +0000, Myklebust, Trond wrote:
> On Tue, 2013-03-19 at 10:50 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 19, 2013 at 02:41:42PM +0000, Myklebust, Trond wrote:
> > > On Tue, 2013-03-19 at 10:32 -0400, J. Bruce Fields wrote:
> > > > (Sorry for the digression, I was just trying to decide whether I can get
> > > > away with turning on 4.1 by default before implementing SP4_MACH_CRED or
> > > > GSS on the backchannel....)
> > >
> > > If you don't, could you please at least offer up a module parameter that
> > > allows me to do that? The current thing is a PITA, since it isn't
> > > supported by any distro scripts, and it requires you to switch off the
> > > server in order to change the version pseudofile contents.
> >
> > The module parameter on its own wouldn't help with that.
> >
> > We could probably fix the pseudofile interface to allow changing the
> > version on the fly.
> >
> > My vague plan was to teach rpc.nfsd to read this (and other parameters)
> > from a config file, so then it'd be "vi /etc/nfsd && service nfsd
> > restart" or equivalent.
> >
> > So is the main thing you want a more convenient interface or a way to
> > change it without rebooting?
>
> Basically, all I want is to enable 4.1 permanently on those servers that
> I want to use for NFSv4.1 testing.
>
> An --enable-nfs-version option for rpc.nfsd that acts together with
> --no-nfs-version as a convenient interface for /proc/fs/nfsd/versions
> would work fine too. All distro configuration scripts that I'm aware of
> allow you to specify optional arguments to rpc.nfsd.
Right, got it. Yes, that's on my todo list.
(But, of course, patches welcomed if someone wants to beat me to it.)
--b.
next prev parent reply other threads:[~2013-03-19 15:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 13:07 [PATCH 01/11] NFSv4: Fail I/O if the state recovery fails irrevocably Trond Myklebust
2013-03-19 13:07 ` [PATCH 02/11] NFS: Don't accept more reads/writes if the open context recovery failed Trond Myklebust
2013-03-19 13:07 ` [PATCH 03/11] NFS: __nfs_find_lock_context needs to check ctx->lock_context for a match too Trond Myklebust
2013-03-19 13:07 ` [PATCH 04/11] NFSv4: The stateid must remain the same for replayed RPC calls Trond Myklebust
2013-03-19 13:07 ` [PATCH 05/11] NFSv4: Resend the READ/WRITE RPC call if a stateid change causes an error Trond Myklebust
2013-03-19 13:07 ` [PATCH 06/11] NFSv4: Prepare for minorversion-specific nfs_server capabilities Trond Myklebust
2013-03-19 13:07 ` [PATCH 07/11] NFSv4.1: Select the "most recent locking state" for read/write/setattr stateids Trond Myklebust
2013-03-19 13:07 ` [PATCH 08/11] NFSv4: Clean up nfs4_opendata_alloc in preparation for NFSv4.1 open modes Trond Myklebust
2013-03-19 13:07 ` [PATCH 09/11] NFSv4.1: Add xdr support for CLAIM_FH and CLAIM_DELEG_CUR_FH opens Trond Myklebust
2013-03-19 13:07 ` [PATCH 10/11] NFSv4.1: Enable open-by-filehandle Trond Myklebust
2013-03-19 13:07 ` [PATCH 11/11] NFSv4.1: Use CLAIM_DELEG_CUR_FH opens when available Trond Myklebust
2013-03-19 14:09 ` [PATCH 10/11] NFSv4.1: Enable open-by-filehandle J. Bruce Fields
2013-03-19 14:16 ` Myklebust, Trond
2013-03-19 14:32 ` J. Bruce Fields
2013-03-19 14:41 ` Myklebust, Trond
2013-03-19 14:45 ` Myklebust, Trond
2013-03-19 15:16 ` J. Bruce Fields
2013-03-19 14:50 ` J. Bruce Fields
2013-03-19 15:16 ` Myklebust, Trond
2013-03-19 15:23 ` J. Bruce Fields [this message]
2013-03-19 16:37 ` Myklebust, Trond
2013-03-21 15:25 ` J. Bruce Fields
2013-03-25 20:12 ` Steve Dickson
2013-03-19 17:29 ` Adamson, Andy
2013-03-19 17:42 ` Myklebust, Trond
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=20130319152304.GG7912@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--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;
as well as URLs for NNTP newsgroup(s).