Earlier yesterday I answered the question about "why NFSv3?" in simple terms. Chuck and Christoph rejected it. I'm _not_ being evassive. There isn't a lot to it: "More efficient NFS in containers" _is_ the answer. But hopefully this email settles "why NFSv3?". If not, please help me (or others) further your understanding by reframing your NFSv3 concern in terms other than "why NFSv3?". Why NFSv3? ---------- The localio feature improves IO performance when using NFSv3 and NFSv4 with containers. Hammerspace has immediate need for the NFSv3 support, because its "data movers" use NFSv3, but NFSv4 support is expected to be useful in the future. Why not use pNFS? ----------------- Just because Hammerspace is very invested in pNFS doesn't mean all aspects are framed in terms of it. The complexity of a pNFS-based approach to addressing localio makes it inferior to the proposed solution of an autonomous NFS client and server rendezvous to allow for network bypass. There is no need for pNFS and by not using pNFS the localio feature is accessible for general NFSv3 and NFSv4 use. Answering "Why NFSv3?" with questions: -------------------------------------- 1) Why wasn't general NFS localio bypass controversial 3 weeks ago? Instead (given all inputs, NFSv3 support requirement being one of them) the use of a "localio protocol" got broad consensus and buyin from Chuck, Jeff, and Neil. I _thought_ we all agreed localio was a worthwhile _auxilliary_ addition to Linux's NFS client and server (to give them awareness of each other through nfs_common) regardless of NFS protocol version. That is why I registered a localio RPC program number with IANA, at Chuck's suggestion, see: https://www.iana.org/assignments/rpc-program-numbers/rpc-program-numbers.txt $ cat rpc-program-numbers.txt | egrep 'Snitzer|Myklebust|Lever' Linux Kernel Organization 400122 nfslocalio [Mike_Snitzer][Trond_Myklebust][Chuck_Lever] [Chuck_Lever] Chuck Lever mailto:chuck.lever&oracle.com 2024-06-20 [Mike_Snitzer] Mike Snitzer mailto:snitzer&kernel.org 2024-06-20 [Trond_Myklebust] Trond Myklebust mailto:trondmy&hammerspace.com 2024-06-20 2) If we're introducing a general NFS localio bypass feature _and_ NFSv3 is important to the stakeholder proposing the feature _and_ NFSv3 support is easily implemented and supported: then why do you have such concern about localio supporting NFSv3? 3) Why do you think NFSv3 unworthy? Is this just a bellweather for broader opposition to flexfiles (and its encouraging more use of NFSv3)? Flexfiles is at the heart of NFSv3 use at Hammerspace. I've come to understand from Chuck and Christoph that the lack of flexfiles support in NFSD helps fuel dislike for flexfiles. That's a lot for me to unpack, and pretty far removed from "why NFSv3?", so I'd need more context than I have if Hammerspace's use of flexfiles is what is fueling your challenge of localio's NFSv3 support. ... Reiterating and then expanding on my earlier succinct answer: localio supporting NFSv3 is beneficial for NFSv3 users (NFSv3 in containers). Hammerspace needs localio to work with NFSv3 to assist with its "data movers" that run on the host (using nfs [on host] and nfsd [within container]). Now you can ask why _that_ is.. but it really is pretty disjoint from the simple matter of ensuring localio support both NFSv3 and NFSv4. I've shared that Hammerspace's "data movers" use NFSv3 currently, in the future they could use NFSv4 as needed. Hence the desire to support localio with both NFSv3 and NFSv4. [when I picked up the localio code NFSv4 wasn't even supported yet].
