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

NeilBrown
2024-07-10T00:10:31Z

On Mon, 08 Jul 2024, Christoph Hellwig wrote:
> On Mon, Jul 08, 2024 at 02:03:02PM +1000, NeilBrown wrote:
> > > I did not say that we have the exact same functionality available and
> > > there is no work to do at all, just that it is the standard way to bypass
> > > the server.
> >
> > Sometimes what you don't say is important. As you acknowledge there is
> > work to do. Understanding how much work is involved is critical to
> > understanding that possible direction.
>
> Of course there is. I've never said we don't need to do any work,
> I'm just asking why we are not using the existing infrastruture to do
> it.
>
> > But pNFS is about handing out grants using standardised protocols that
> > support interoperability between distinct nodes, and possibly distinct
> > implementations. localio doesn't need any of that. It all exists in a
> > single implementation on a single node. So in that sense there can be
> > expected to be different priorities.
> >
> > Why should we pay the costs of pNFS when implementing localio?
>
> Why do you think we pay a cost for it? From all I can tell it makes
> the job simpler, especially if we want to do things like bypassing
> the second page cache.
>
> > That
> > question can only be answered if we have a good understanding of the
> > costs and benefits. And that requires having a concrete proposal for
> > the "pNFS" option - if only a detailed sketch.
>
> I sketched the the very sketchy sketch earlier - add a new localio
> layout that does local file I/O. The I/O side of that is pretty
> tivial, and maybe I can find some time to write draft code. The file
> open side is just as horrible as in the current localio proposal,
> and I could just reuse that for now, although I think the concept
> of opening the file in the client contect is fundamentally wrong
> no matter how we skin the cat.
>

I had been assuming that you were proposing a new pNFS layout type with
associated protocol extension, an RFC describing them, and navigation of
the IETF standards process. These are (some of) the costs I was
thinking of. Of course the IETF requires demonstration of
interoperability between multiple implementations, and as that is
impossible for localio, we would fail before we started.

But I now suspect that I guessed your intention wrongly (I'm rubbish at
guessing other people's intentions). Your use of the word
"infrastructure" above and the sketchy sketch you provide (thanks) seems
to indicate you are only suggesting that we re-use some of the pnfs
abstractions and interfaces already implemented in the Linux NFS client
and server.

Is that what you mean?

If it is, then it isn't immediately clear to me that this would have to
be NFSv4 only. The different versions already share code where that
makes sense. Moving the pnfs code from the nfsv4 module to a new pnfs
module which nfsv3 also depends on might make sense.

I'm keen to know what you are really thinking.

Thanks,
NeilBrown