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. Ben
