> On Mar 25, 2021, at 11:03 AM, Nagendra Tomar <Nagendra.Tomar@xxxxxxxxxxxxx> wrote: > >> I've been thinking of the write-to-sysfs approach as just the kernel >> interface. I would expect there to be some future userspace tool built >> on the sysfs files that is easier for admins to use. This future tool >> could probably be coded to handle dns resolutions and write the result >> to the sysfs file. > > Yeah, I got the idea. I was hoping to avoid any additional userspace tool. > IIUC the userspace tool would be more like an always-running program that > periodically does the name resolution and updates the sysfs xprt addr > file. It can be done using mount helpers which take the NFS server's hostname > and start the process to periodically resolve the hostname and write to sysfs. > Then on unmount the program has to be stopped. Well there are variations on this idea. One variation might be a single orchestrator daemon that would manage the sysfs files using inotify, so it wouldn't have to track the operation of mount/umount. The sysfs files are meant to be only a conduit. User space is meant to dynamically provide settings based on policy. The opportunity here is to make this something that can be active and rules-based instead of a static configuration (ie, more like udev and less like /etc/fstab). And note that any solution has to be container-aware. mount certainly is, and that's another reason why the DNS query is done at that time. An upcall would have to be done in the same namespace(s) as the mount was done. (I'm not advocating any particular approach, merely pointing out some things that need consideration). > With the dns resolution upcall on reconnect, all of this could be avoided. > Infact as Olga said, if we extend your patch to treat hostnames specially - > do dns resolution upcall if the sysfs has the hostname instead of IP address, > that will serve my usecase well too. > > Thanks, > Tomar -- Chuck Lever
