From: Steve Dickson <SteveD@RedHat.com>
To: NeilBrown <neilb@suse.de>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf
Date: Tue, 18 May 2021 08:38:58 -0400 [thread overview]
Message-ID: <07b66f08-be94-9b3c-723f-cea880ab4b1d@RedHat.com> (raw)
In-Reply-To: <162086574506.5576.4995500938909500647@noble.neil.brown.name>
Sorry for the delay... I took some PTO...
On 5/12/21 8:29 PM, NeilBrown wrote:
> On Fri, 16 Apr 2021, Steve Dickson wrote:
>> Hey Chuck!
>>
>> On 4/14/21 7:26 PM, Chuck Lever III wrote:
>>> Hi Steve-
>>>
>>>> On Apr 14, 2021, at 2:10 PM, Steve Dickson <SteveD@redhat.com> wrote:
>>>>
>>>> This is a tweak of the patch set Alice Mitchell posted last July [1].
>>>
>>> That approach was dropped last July because it is not container-aware.
>>> It should be simple for someone to write a udev script that uses the
>>> existing sysfs API that can update nfs4_client_id in a namespace. I
>>> would prefer the sysfs/udev approach for setting nfs4_client_id,
>>> since it is container-aware and makes this setting completely
>>> automatic (zero touch).
>> As I said in in my cover letter, I see this more as introduction of
>> a mechanism more than a way to set the unique id. The mechanism being
>> a way to set kernel module params from nfs.conf. The setting of
>> the id is just a side effect...
>
> I wonder if this is the best approach for setting module parameters.
>
> rpc.nfsd already sets grace-time and lease-time - which aren't
> exactly module parameters, but are similar - using values from nfs.conf.
> Similarly statd sets /proc/fs/nfs/nlm_tcport based on nfs.conf.
>
> I don't think these things should appear in nfs.conf as "kernel
> parameters", but as service parameters for the particular service.
> How they are communicate to the kernel is an internal implementation
> detail. Maybe it will involve setting module parameters (at least on
> older kernels).
I think I understand you idea of look at thing as "service parameters"
instead of "kernel parameters", but looking at the actual parameters
that might be a bit difficult.
Some do map to a service like nfs4_disable_idmapping could be set
from /etc/idmapd.conf, but things like send_implementation_id or
delegation_watermark do not really map to a particular service
or am I missing something?
>
> For the "identity" setting, I think it would be best if this were
> checked and updated by mount.nfs (similar to the way mount.nfs will
> check if statd is running, and will start it if necessary). So should
> it go in nfsmount.conf instead of nfs.conf?? I'm not sure.
Interesting idea...I would think nfsmount.conf would be the
right place.
>
> It isn't clear to me where the identity should come from.
> In some circumstances it might make sense to take it from nfs.conf.
> In that case we would want to support reading /etc/netnfs/NAME/nfs.conf
> where NAME was determined in much the same way that "ip netns identify"
> determines a name. (Compare inum of /proc/self/ns/net with the inum of
> each name in /run/netns/).
I think supporting configs per namespaces is a good idea. I don't
think it would be too difficult to do since we already support
the nfs.d directory.
> If we did that, we could then support "$netns" in the conf file, and
> allow
>
> [nfs]
> identity = ${hostname}-${netns}
>
> in /etc/nfs.conf, and it would Do The Right Thing for many cases.
I'm a bit namespace challenged... but as I see it using
"ip netns identify" (w/out the [PID]) would return all of
the current network network namespaces. Then we would run through
the /etc/nfs.conf.d/ directory looking for a matching directory
for any of the returned namespaces. If found that config
would be used. Something along those lines?
With multiple namespaces, how would we know which one to use?
>
> We have a partner who wants to make use of 'nconnect' but is
> particularly inconvenienced by the fact that once there is any mount
> from a given server it is no longer possible to change the nconnect
> setting. I have suggested they explore setting up a separate
> net-namespace for "their" mounts which can be independent from "other"
> mounts on the same machine. If we could make that work with a degree of
> transparency - maybe even a "-o netfs=foobar" mount option - that would
> be a big help.
I think I would like to continue exploring the namespace patch verse
adding another mount option.
steved.
next prev parent reply other threads:[~2021-05-18 12:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 18:10 [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf Steve Dickson
2021-04-14 18:10 ` [PATCH 1/3] nfs-utils: Enable the retrieval of raw config settings without expansion Steve Dickson
2021-05-06 17:29 ` Steve Dickson
2021-04-14 18:10 ` [PATCH 2/3] nfs-utils: Add support for further ${variable} expansions in nfs.conf Steve Dickson
2021-04-14 18:10 ` [PATCH 3/3] nfs-utils: Update nfs4_unique_id module parameter from the nfs.conf value Steve Dickson
2021-04-14 23:26 ` [PATCH 0/3] Enable the setting of a kernel module parameter from nfs.conf Chuck Lever III
2021-04-15 15:33 ` Steve Dickson
2021-04-15 16:37 ` Chuck Lever III
2021-04-15 23:30 ` Trond Myklebust
2021-04-16 0:40 ` Trond Myklebust
2021-04-17 16:33 ` Steve Dickson
2021-04-17 18:09 ` Trond Myklebust
2021-04-17 16:18 ` Steve Dickson
2021-04-17 16:36 ` Chuck Lever III
2021-04-17 17:50 ` Steve Dickson
2021-04-18 16:51 ` Chuck Lever III
2021-04-20 13:11 ` Steve Dickson
2021-04-20 14:09 ` Chuck Lever III
2021-04-20 14:31 ` Trond Myklebust
2021-04-20 17:18 ` J. Bruce Fields
2021-04-20 17:28 ` Trond Myklebust
2021-04-20 17:40 ` bfields
2021-04-20 17:53 ` Trond Myklebust
2021-04-20 18:16 ` bfields
2021-04-20 19:30 ` Steve Dickson
2021-04-20 18:47 ` Steve Dickson
2021-04-20 18:26 ` Steve Dickson
2021-05-13 0:29 ` NeilBrown
2021-05-18 12:38 ` Steve Dickson [this message]
2021-05-21 2:39 ` NeilBrown
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=07b66f08-be94-9b3c-723f-cea880ab4b1d@RedHat.com \
--to=steved@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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.