On Feb 2, 2021, at 5:24 PM, Trond Myklebust [off-list ref] wrote:

On Tue, 2021-02-02 at 22:21 +0000, Chuck Lever wrote:

quoted

quoted

On Feb 2, 2021, at 5:17 PM, Trond Myklebust <
trondmy@hammerspace.com> wrote:

On Tue, 2021-02-02 at 14:49 -0500, Benjamin Coddington wrote:

quoted

On 2 Feb 2021, at 14:24, Dan Aloni wrote:

quoted

On Tue, Feb 02, 2021 at 01:52:10PM -0500, Anna Schumaker wrote:

quoted

You're welcome! I'll try to remember to CC him on future
versions
On Tue, Feb 2, 2021 at 1:51 PM Chuck Lever
[off-list ref] wrote:

quoted

I want to ensure Dan is aware of this work. Thanks for
posting,
Anna!

Thanks Anna and Chuck. I'm accessing and monitoring the mailing
list via
NNTP and I'm also on #linux-nfs for chatting (da-x).

I see srcaddr was already discussed, so the patches I'm
planning to
send
next will be based on the latest version of your patchset and
concern
multipath.

What I'm going for is the following:

- Expose transports that are reachable from xprtmultipath. Each
in
its
  own sub-directory, with an interface and status
representation
similar
  to the top directory.
- A way to add/remove transports.
- Inspiration for coding this is various other things in the
kernel
that
  use configfs, perhaps it can be used here too.

Also, what do you think would be a straightforward way for a
userspace
program to find what sunrpc client id serves a mountpoint? If
we
add an
ioctl for the mountdir AFAIK it would be the first one that the
NFS
client supports, so I wonder if there's a better interface that
can
work
for that.

I'm a fan of adding an ioctl interface for userspace, but I think
we'd
better avoid using NFS itself because it would be nice to someday
implement
an NFS "shutdown" for non-responsive servers, but sending any
ioctl
to the
mountpoint could revalidate it, and we'd hang on the GETATTR.

Maybe we can figure out a way to expose the superblock via sysfs
for
each
mount.

Right. There is potential functionality here that we do not need or
even want to expose via the mount interface. Being able to cancel
all
the hung RPC calls in an RPC queue, for instance, is not something
you
want to do through fsopen() and friends.

I thought we were talking only about an ioctl or fsopen cmd that
identifies the transports that are associated with an NFS mount.

Ostensibly a read-only use of that API.

I'll let Anna chime in with the details of her use case, but my
understanding has always been that this would be a read/write interface
for changing the properties of those transports on the fly.

Agreed, but Dan's looking for a way to match up an NFS mount to the
/sys directories that Anna is adding to do those manipulations.

So, fsopen() or ioctl() would identify the transports, and then
Anna's API would enable an appropriately privileged user to
change the properties as you indicated. Two separate steps.

If the new API already provides a mechanism to determine which
transports to adjust, then we won't need an ioctl/fsopen at all.


--
Chuck Lever