On Wed, Jul 03, 2024 at 05:19:06PM +0000, Chuck Lever III wrote: > > > > On Jul 3, 2024, at 11:36 AM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > > On Wed, Jul 03, 2024 at 03:24:18PM +0000, Chuck Lever III wrote: > > > >> IMO the design document should, as part of the problem statement, > >> explain why a pNFS-only solution is not workable. > > > > Sure, I can add that. > > > > I explained the NFSv3 requirement when we discussed at LSF. > > You explained it to me in a private conversation, although > there was a lot of "I don't know yet" in that discussion. Those "I don't know yet" were in response to you asking why a pNFS layout (like the block layout) is not possible to achieve localio. The answer to that is: someone(s) could try that, but there is no interest from me or my employer to resort to using block layout with centralized mapping of which client and DS are local so that the pNFS MDS could handout such pNFS block layouts. That added MDS complexity can be avoided if the client and server have autonomy to negotiate more performant access without a centralized arbiter (hence the "localio" handshake). > It needs to be (re)explained in a public forum because > reviewers keep bringing this question up. Sure. > I hope to see more than just "NFSv3 is in the mix". There > needs to be some explanation of why it is necessary to > support NFSv3 without the use of pNFS flexfile. Loaded question there, not sure why you're leading with it being invalid to decouple localio (leveraging client and server locality) from pNFS. NFS can realize benefits from localio being completely decoupled from flexfiles and pNFS. There are clear benefits with container use-cases that don't use pNFS at all. Just so happens that flexfiles ushers in the use of NFSv3. Once the client gets a flexfiles layout that points to an NFSv3 DS: the client IO is issued in terms of NFSv3. If the client happens to be on the same host as the server then using localio is a win.
