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
