On Tue, Feb 02, 2021 at 02:49:38PM -0500, Benjamin Coddington wrote: > On 2 Feb 2021, at 14:24, Dan Aloni wrote: > > 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. For that, I was looking into using openat2() with the very recently added RESOLVE_CACHED flag. However from some experimentation I see that it still sleeps on the unresponsive mount in nfs_weak_revalidate(), and the latter cannot tell whether LOOKUP_CACHED flag was passed to d_weak_revalidate(). > Maybe we can figure out a way to expose the superblock via sysfs for each > mount. Essentially this is what fspick() syscall lets you do. I imagine that it can be implemented entirely under fs/nfs, using fsconfig() from under a FSCONFIG_SET_STRING passing a special string such as "report-clients-ids", causing a list of sunrpc client IDs to get written to the fs_context log. However even with this interface we may still need to verify that the path lookup that `fspick` does using `user_path_at` is not blocking on non-responsive NFS mounts. -- Dan Aloni
