Re: [PATCH v11 00/20] nfs/nfsd: add support for localio

Mike Snitzer
2024-07-03T15:28:56Z

On Wed, Jul 03, 2024 at 08:16:00AM -0700, Christoph Hellwig wrote:
> I've stated looking a bit at the code, and the architectural model
> confuses me more than a bit.
>
> A first thing that would be very helpful is an actual problem statement.
> The only mention of a concrete use case is about containers, implying
> that this about a client in one container/namespace with the server
> or the servers in another containers/namespace. Is that the main use
> case, are there others?

Containers is a significant usecase, but also any client that might
need to access local storage efficiently (e.g. GPU service running NFS
client that needs to access NVMe on same host).

> I kinda deduct from that that the client and server probably do not
> have the same view and access permissions to the underlying file
> systems? As this would defeat the use of NFS I suspect that is the
> case, but it should probably be stated clearly somewhere.

I can tighten that up in the Documentation.

> Going from there I don't understand why we need multiple layers of
> server bypass. The normal way to do this in NFSv4 is to use pNFS
> layout.
>
> I.e. you add a pnfs localio layout that just does local reads
> and writes for the I/O path. We'd still need a way to find a good
> in-kernel way to get the file structure, but compared to the two
> separate layers of bypasses in the current code it should be
> significantly simpler.

Using pNFS layout isn't viable because NFSv3 is very much in the mix
(flexfiles layout) for Hammerspace.