On Mon, Jun 17, 2024 at 09:08:59PM -0400, Mike Snitzer wrote: > Hi, > > This v4 fixes a few bugs in v3, reorders patches and improves patch > headers and code documentation. Please pay particular attention to > patches 17 and 18. > > If all looks good to others, for v5 I can rebase to the -next trees > for nfs and nfsd. > > My git tree is here: > https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/ > > This v4 is both branch nfs-localio-for-6.11 (always tracks latest) > and nfs-localio-for-6.11.v4 > > nfs-localio-for-6.11.v3, nfs-localio-for-6.11.v2 and > nfs-localio-for-6.11.v1 are also there. > > To see the changes from v3 to v4 please do: > git remote add snitzer git://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git > git remote update snitzer > git diff snitzer/nfs-localio-for-6.11.v3 snitzer/nfs-localio-for-6.11.v4 > > These changes have proven stable against various test scenarios: > 1) client and server both on localhost (for both v3 and v4.2) > 2) various permutations of client and server support enablement for > both local and remote client and server. > 3) client on host, server within a container (for both v3 and v4.2) > My container testing was in terms of podman managed containers. > 4) container stop/restart scenario documented in the last patch > > All review and comments are welcome! With my NFSD maintainer hat on: I'm concerned about some of the long-term maintenance work being added by this series. This is more of a concern on the client side, for sure, but, IMO: In a perfect world, we would have an RFC for this, and the set would come with tests we can add to our release CI framework. I'm not holding you to all that, but I would like to see something to help me out in the long-run. Because this is not part of an Internet standard, this patch set needs to come with some architectural documentation like something under Documentation/filesystems/nfs. It needs to explain the use cases and why this design was chosen. It should have a specification for the LOCALIO protocol. It needs to explain how to test the facility being added -- basically we need to know how /not/ to break this thing as we develop around it. I'm also interested to know who, besides Hammerspace, can benefit from this facility. (This isn't a hard objection, just a request for some help with the long-term maintenance burden). -- Chuck Lever
