> On Feb 2, 2021, at 5:24 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2021-02-02 at 22:21 +0000, Chuck Lever wrote: >> >> >>> 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. >> > > 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
