> On Feb 2, 2021, at 5:17 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2021-02-02 at 14:49 -0500, Benjamin Coddington wrote: >> On 2 Feb 2021, at 14:24, Dan Aloni wrote: >> >>> On Tue, Feb 02, 2021 at 01:52:10PM -0500, Anna Schumaker wrote: >>>> 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 >>>> <chuck.lever@xxxxxxxxxx> wrote: >>>>> >>>>> 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. -- Chuck Lever
