On Thu, Aug 29, 2024 at 12:59:20PM -0400, Mike Snitzer wrote: > On Thu, Aug 29, 2024 at 12:49:23PM -0400, Jeff Layton wrote: > > On Wed, 2024-08-28 at 21:04 -0400, Mike Snitzer wrote: > > > From: Weston Andros Adamson <dros@xxxxxxxxxxxxxxx> > > > > > > Add server support for bypassing NFS for localhost reads, writes, and > > > commits. This is only useful when both the client and server are > > > running on the same host. > > > > > > If nfsd_open_local_fh() fails then the NFS client will both retry and > > > fallback to normal network-based read, write and commit operations if > > > localio is no longer supported. > > > > > > Care is taken to ensure the same NFS security mechanisms are used > > > (authentication, etc) regardless of whether localio or regular NFS > > > access is used. The auth_domain established as part of the traditional > > > NFS client access to the NFS server is also used for localio. Store > > > auth_domain for localio in nfsd_uuid_t and transfer it to the client > > > if it is local to the server. > > > > > > Relative to containers, localio gives the client access to the network > > > namespace the server has. This is required to allow the client to > > > access the server's per-namespace nfsd_net struct. > > > > > > CONFIG_NFSD_LOCALIO controls the server enablement for localio. > > > A later commit will add CONFIG_NFS_LOCALIO to allow the client > > > enablement. > > > > Do we need separate CONFIG options? Surely if you have one, you'll > > always want the other. > > We used to have 4 (2 for each)... yeah I hear you. Its fiddley but I > can look at making it a single one with more feeling. Same as the > nfs_to opes work I just commited to: worst case we keep what we have > with the 2 CONFIG options, but 1 option _should_ be doable. I also had Jeff's question but it didn't boil up out of my subconsciousness into my typing fingers. Seems like having a single Kconfig option would make this slightly easier for downstream consumers (ie, Linux distros). -- Chuck Lever
