On Wed, Mar 29, 2017 at 09:06:50AM -0400, Stephen Gallagher wrote:
On 03/28/2017 09:54 PM, J. Bruce Fields wrote:
> I think the thread count is another commonly needed parameter--the
> default of 8 threads is a little small.
>
So, this is a feature like the ID-mapping and stuff that I'm beginning
to think probably should be a separate Ansible module specifically for
configuring global settings of the NFS server. So perhaps we should
rename the module described in this proposal to "nfs_share" rather
than just "nfs" and use the name "nfs" for that purpose.
Note also that a lot of those settings will only take effect on server
restart.
Also, you generally want to restart after an export removal. (The
unexport will work, but often people are unexporting so they can
unmount, and that's not reliable as knfsd can still hold some filesystem
references after the unexport.)
Anyway, maybe none of that's Ansible's problem, but it's worth at least
mentioning in documentation if there's a chance.
> "remote_path is in there as a future-compatible option; in
the container
> world, we may have the ability to "fake" the mount point to the client,
> so I added that as an option here. I'm not sure whether to keep it or
> drop it." I'm not sure containers would do that for you. Once upon a
> time I had rpc.mountd patches to implement this, but wasn't sure if it
> was an interesting feature to anyone.
Well, if nothing else we could always have the module just do a bind mount of
the local_path location into the remote_path location so that it could be
referenced by the latter name; I don't think it would require any changes to the
existing NFS server.
Remembering now what I did a few years ago: I did bind mounts under
/var/lib/nfsroot/ (or something like that) then added support for a new
rpc.mountd option so e.g. like "nfsroot=/var/lib/nfsroot/" would make a
path "/var/lib/nfsroot/export" mountable by a client as just
"/export".
--b.