Re: [PATCH v2 0/5] SUNRPC: Create sysfs files for changing IP

[Trond Myklebust <trondmy@hammerspace.com>]

On Tue, 2021-02-02 at 22:21 +0000, Chuck Lever wrote:
> 
> 
> > 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:
> > > 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@oracle.com> 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@hammerspace.com