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. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
