Re: [PATCH nfs-utils v6 0/3] nfsdctl: add a new nfsdctl tool to nfs-utils

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 7/26/24 6:20 PM, Jeff Layton wrote:
On Fri, 2024-07-26 at 17:59 -0400, Steve Dickson wrote:

On 7/26/24 5:32 PM, Jeff Layton wrote:
On Fri, 2024-07-26 at 15:40 -0400, Steve Dickson wrote:
Hey!

On 7/22/24 1:01 PM, Jeff Layton wrote:
Hi Steve,

Here's an squashed version of the nfsdctl patches, that represents
the latest changes. Let me know if you run into any other problems,
and thanks for helping to test this!

Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
---
Changes in v6:
- make the default number of threads 16 in autostart
- doc updates

Changes in v5:
- add support for pool-mode setting
- fix up the handling of nfsd_netlink.h in autoconf
- Link to v4:
https://lore.kernel.org/r/20240604-nfsdctl-v4-0-a2941f782e4c@xxxxxxxxxx

Changes in v4:
- add ability to specify an array of pool thread counts in nfs.conf
- Link to v3:
https://lore.kernel.org/r/20240423-nfsdctl-v3-0-9e68181c846d@xxxxxxxxxx

Changes in v3:
- split nfsdctl.h so we can include the UAPI header as-is
- squash the patches together that added Lorenzo's version and
convert
     it to the new interface
- adapt to latest version of netlink interface changes
     + have THREADS_SET/GET report an array of thread counts (one per
pool)
     + pass scope in as a string to THREADS_SET instead of using
unshare() trick

Changes in v2:
- Adapt to latest kernel netlink interface changes (in particular,
send
     the leastime and gracetime when they are set in the config).
- More help text for different subcommands
- New nfsdctl(8) manpage
- Patch to make systemd preferentially use nfsdctl instead of
rpc.nfsd
- Link to v1:
https://lore.kernel.org/r/20240412-nfsdctl-v1-0-efd6dcebcc04@xxxxxxxxxx

---
Jeff Layton (3):
         nfsdctl: add the nfsdctl utility to nfs-utils
         nfsdctl: asciidoc source for the manpage
         systemd: use nfsdctl to start and stop the nfs server

    configure.ac                 |   19 +
    systemd/nfs-server.service   |    4 +-
    utils/Makefile.am            |    4 +
    utils/nfsdctl/Makefile.am    |   13 +
    utils/nfsdctl/nfsd_netlink.h |   96 +++
    utils/nfsdctl/nfsdctl.8      |  304 ++++++++
    utils/nfsdctl/nfsdctl.adoc   |  158 +++++
    utils/nfsdctl/nfsdctl.c      | 1570
++++++++++++++++++++++++++++++++++++++++++
    utils/nfsdctl/nfsdctl.h      |   93 +++
    9 files changed, 2259 insertions(+), 2 deletions(-)
---
base-commit: b76dbaa48f7c239accb0c2d1e1d51ddd73f4d6be
change-id: 20240412-nfsdctl-fa8bd8430cfd

The patches apply very cleaning and thank you
for squashing them down... but... bring up the
NFS server with 'nfsdctl autostart' v3 is not
being registered with rpcbind which means
v3 mount will not work.

Just curious are you trying support my
idea of deprecating V3 :-) (That's a joke!)

steved.


You do need a patched kernel for this:

      https://lore.kernel.org/linux-nfs/Zp5j2DW+2BNaIPif@xxxxxxxxxxxxxxxxxxxxxx/T/#e675642639c59b1c0070f4b19cd03b89cff7983ba

With a patched kernel, I get this with autostart:

[kdevops@kdevops-nfsd ~]$ rpcinfo -p
     program vers proto   port  service
      100000    4   tcp    111  portmapper
      100000    3   tcp    111  portmapper
      100000    2   tcp    111  portmapper
      100000    4   udp    111  portmapper
      100000    3   udp    111  portmapper
      100000    2   udp    111  portmapper
      100024    1   udp  42104  status
      100024    1   tcp  40159  status
      100003    3   udp   2049  nfs
      100227    3   udp   2049  nfs_acl
      100003    3   tcp   2049  nfs
      100003    4   tcp   2049  nfs
      100227    3   tcp   2049  nfs_acl
      100021    1   udp  46387  nlockmgr
      100021    3   udp  46387  nlockmgr
      100021    4   udp  46387  nlockmgr
      100021    1   tcp  36565  nlockmgr
      100021    3   tcp  36565  nlockmgr
      100021    4   tcp  36565  nlockmgr


Are you seeing different results?
Yup
uname -r
6.11.0-0.rc0.20240724git786c8248dbd3.12.fc41.x86_64 (rawhide)


Did you patch that kernel by hand then? AFAICT, that git hash doesn't
have the necessary fix. I don't think Chuck has sent a PR to Linus for
it just yet.
No I did not... Due to the fact I can not commit theses
patches until the kernel patch land into the distros.

steved.





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux