Project

General

Profile

Actions

Bug #16447

open

NFS 4.1 OPEN and OPEN_DOWNGRADE need proper implementation of WANT DELEG support

Added by Toomas Soome about 2 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
nfs - NFS server and client
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

NFS 4.1 did add WANT DELEG flags to help to fine tune the delegation features, via share_access parameter. Current implementation has added deleg_want variable in OPEN4args structure, but this seems to be bad decision, because OPEN4args should reflect the protocol declaration and since share_access values are defined as bit fields, I do not think we need to have separate structure field for WANT flags.


Related issues

Related to illumos gate - Bug #16438: NFS4 xdr_share_access() fails to handle XDR_ENCODE pathClosedToomas Soome

Actions
Related to illumos gate - Feature #15405: Port NFSv41 baseClosedToomas Soome

Actions
Blocked by illumos gate - Bug #16390: BACKCHANNEL op implementation.In ProgressToomas Soome

Actions
Actions #1

Updated by Toomas Soome about 2 months ago

  • Related to Bug #16438: NFS4 xdr_share_access() fails to handle XDR_ENCODE path added
Actions #2

Updated by Toomas Soome about 2 months ago

Actions #3

Updated by Vitaliy Gusev about 2 months ago

deleg_want idea is similar as implemented in Linux. This simplifies getting and analysing requests for delegations. So I guess it shouldn't be removed. Instead, XDR code should be expanded to have information what protocol version it handles:

  • NFSv4.0 ENCODE just ignores `deleg_want`
  • NFSv4.1+ ENCODE encodes according to OPEN4_SHARE_WANT_MASK
Actions #4

Updated by Vitaliy Gusev about 2 months ago

This `deleg_want` field can be used after adding back-channel support.

Actions #5

Updated by Vitaliy Gusev about 2 months ago

  • Blocked by Bug #16390: BACKCHANNEL op implementation. added
Actions #6

Updated by Vitaliy Gusev about 2 months ago

  • Assignee set to Vitaliy Gusev

s

Actions #7

Updated by Gordon Ross about 2 months ago

I’m afraid some may be missing the point on why this bug was opened.
The types described in the XDR sources normally should directly generate the over-the-wire types. Presented types at function calls sometimes have allowances for conversion done for convenience (strings are a good example of that).
Other than that, having RPC structure types differ significantly from what the program.x file specifies is poor practice. This bug is asking for that practice to be removed from xdr_share_access.
Specifically, the deleg_want member does not appear in the RFC nor the proto.x file and should not be part of that structure as currently defined.

Actions #8

Updated by Vitaliy Gusev about 2 months ago

Gordon Ross wrote in #note-7:

I’m afraid some may be missing the point on why this bug was opened.
The types described in the XDR sources normally should directly generate the over-the-wire types. Presented types at function calls sometimes have allowances for conversion done for convenience (strings are a good example of that).
Other than that, having RPC structure types differ significantly from what the program.x file specifies is poor practice. This bug is asking for that practice to be removed from xdr_share_access.

xdr_share_access should not be removed because it needs to decode packed information and encode structures.

XDR procedures get structures that does not conform to program.x directly. Instead XDR procedures decode packed data to those structures and wise verse.

Please do not confuse that.

Actions #9

Updated by Vitaliy Gusev about 2 months ago

That really is needed for XDR and I will open ticket for that -
- have information about what protocol version currently ENCODED/DECODED. Because NFSv4.0 do not use some additional fields which could be just uninitialised. And there is also some more complex things in encoding and decoding for NFSv4.0 and NFSv4.1+

Current XDR implementation doesn't have it and that introduces misunderstanding about right ENCODE and DECODE.

Actions

Also available in: Atom PDF