> On Jan 14, 2021, at 3:29 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Wed, Jan 13, 2021 at 9:18 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> >>> On Jan 13, 2021, at 2:48 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>> >>>> On Jan 13, 2021, at 2:23 PM, Anna Schumaker <schumaker.anna@xxxxxxxxx> wrote: >>>> >>>> On Tue, Jan 12, 2021 at 11:59 AM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >>>>> >>>>> On Tue, Jan 12, 2021 at 08:09:09AM -0500, Chuck Lever wrote: >>>>>> Hi Anna- >>>>>> >>>>>>> On Jan 11, 2021, at 4:41 PM, schumaker.anna@xxxxxxxxx wrote: >>>>>>> >>>>>>> From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx> >>>>>>> >>>>>>> It's possible for an NFS server to go down but come back up with a >>>>>>> different IP address. These patches provide a way for administrators to >>>>>>> handle this issue by providing a new IP address for xprt sockets to >>>>>>> connect to. >>>>>>> >>>>>>> This is a first draft of the code, so any thoughts or suggestions would >>>>>>> be greatly appreciated! >>>>>> >>>>>> One implementation question, one future question. >>>>>> >>>>>> Would /sys/kernel/net be a little better? or /sys/kernel/sunrpc ? >>>> >>>> Possibly! I was trying to match /sys/fs/nfs, but I can definitely >>>> change this if another location is better. >>> >>> Ah... since this is a supplement to the mount() interface, maybe >>> placing this new API under /sys/fs/nfs/ might make some sense. >> >> Or you could implement it with "-o remount,addr=new-address". > > A change of address is currently not allowed by the NFS because > multiple mounts might be sharing a superblock and change of one > mount's option would not be correct. The way things work from this new > mechanism is system wide and all mounts are affected. OK, well, if we're going with an API based on /sys that shows underlying transport connections, is there a way to expose whether the connection is established or closed? Maybe also last traffic or last connect attempt? Can it support RPC/RDMA connections too? -- Chuck Lever
