Re: [nfsv4] WGLC for delstid draft

[David Noveck <[e-mail]>]

On Sat, Jul 1, 2023, 10:36 PM Chris Inacio <[e-mail]> wrote:

> Top posting on purpose here - this doesn’t need to carry into any more of
> this thread.
>
> This is a great conversation and the feedback needed to advance the
> document, but my opinion, (as a chair,) is that we need another spin of the
> draft before this is ready to leave the WG.
>

I agree.  That new spin would have to address issues raised during WGLC,
including stuff in my review and Chuck's requests for implementation
information.

I think the details will be discussed in Tom's response to the WGLC issues,
which have been delayed until he feels better.  It makes sense if that
happens on the NFSv4 list.

 Looking forward to the conversation about this.
>
> I also would like to see this on the NFSv4 list - not just with chairs and
> a select few.
>

Up until now the discussion was about clarifying Rick's specific comment so
he and the document authors were necessarily part of "the select few"

Is there any reason not to continue this conversation on list?
>

No.


> ----
> Chris Inacio
> [e-mail]
>
>
>
> On Jul 1, 2023, at 6:41 PM, Rick Macklem <[e-mail]> wrote:
>
> On Sat, Jul 1, 2023 at 1:38 PM Thomas Haynes <[e-mail]>
> wrote:
>
>
>
>
> On Jul 1, 2023, at 1:32 PM, Rick Macklem <[e-mail]> wrote:
>
> On Sat, Jul 1, 2023 at 1:16 PM Trond Myklebust <[e-mail]> wrote:
>
>
>
>
> On Sat, Jul 1, 2023 at 4:01 PM Rick Macklem <[e-mail]>
> wrote:
>
>
> On Sat, Jul 1, 2023 at 12:37 PM David Noveck <[e-mail]> wrote:
>
>
> As this is a  new flag rather than a new operation, I think the proper
> error would be NFS4ERR_INVAL. That applies to v4.0 and v4.1 servers as well
> as v4.2 servers that choose not to implement the feature.
>
> Ok. I misinterpreted "protocol element is a known part of the variant"
> (I assumed "variant" included the extension) of RFC8178 Sec. 4.3.
>
> I do see Sec. 4.4.3 notes that a NFS4ERR_INVAL reply indicates the
> server has no knowledge of the flag bit.
>
> Thanks for the clarification, rick
> ps; If the draft included a implementation experience section that showed
>     significant reductions in RPC/Operation counts, I might be interested
>     in implementing it.
>
>
>
> For small file workloads, it has basically allowed us to reduce the
> open(O_CREATE|O_WRONLY) + write() + close() operation down to 1 synchronous
> calls to our metadata server, 1 (synchronous) write to the pNFS data
> server, and 1 deferred/asynchronous call to the metadata server.
>
> open() -> creates the file and retrieves the attributes + layout as a
> single COMPOUND
> write() -> does a synchronous write operation to the pNFS data server.
> close() is a no-op, since we only hold a delegation, and that can be
> released asynchronously either upon a delegation recall from the server, or
> when the client decides to garbage collect it.
>
> With the standard OPEN operation, we have to throw in a synchronous CLOSE,
> since the latter holds stateful locks, and is not recallable.
>
> IOW: for that kind of workload it reduces the total number of operations
> on the wire by 25% (by eliminating either the CLOSE or the DELEGRETURN). It
> reduces the number of synchronous operations by 33% when the server can
> hand out a delegation (which it usually can for an O_CREATE workload).
>
> Although late in the game, it would nice if this were captured in the
> draft.
>
> I might actually be inspired to implement it, rick
>
>
> So you want small section on real world applications of this?
>
> I think a short implementation experience section would be good.
> (There is mention of IETF's running code mantra right on the
> ietf.org home page.)
>
> If you can encode Trond's above case in the draft, I think that
> justifies the extension quite nicely. (At least it convinces me that
> implementing it is worth the effort.)
>
> rick
>
>
>
>
>
>
>
> On Sat, Jul 1, 2023, 2:54 PM Rick Macklem <[e-mail]> wrote:
>
>
> Assuming all a server needs to do is reply NFS4ERR_NOTSUPP
> (which appears to be what RFC8178 says)
> when the OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION
> flag is specified, then I have no problem
> with it (and no intent on ever implementing it).
>
> I feel that this makes an already complex operation (OPEN)
> even more complex and convoluted, but so long as
> implementation is always optional, so be it.
>
> rick
>
> On Sat, Jul 1, 2023 at 4:13 AM David Noveck <[e-mail]> wrote:
>
>
> I recall you  raised some concerns about the fact that Tom and Trond's
> draft by allowing open to return a delegation stateid and not an open
> stateid might not be a valid extension since you could read some text
> rfc8881 as contradicted by the creation of this extension.
>
> In my view, this text does not foreclose this extension or require that
> the new extension be marked as updating rfc8881. It was never intended that
> extensions to v4.2 had to avoid invalidating statements made about v4.1.
>
> Nevertheless, we need to get consensus so I  have to ask whether you still
> think there is something wrong with this extension and some major
> adjustment is needed before submission.
>
>
>